[BUG] movement too slow with G2/G3

[DerAndere1]

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

No, but I will test it now!

Bug Description

WITH SYNTAX G2/G3 X Y Z I J F THE AXIS DO MOVE BUT VERY SLOWLY

This potential bug was first reported by @printercnc here: #55 (comment)

Bug Timeline

unknown

Expected behavior

Feedrate should be accoring to parameter F

Actual behavior

Feedrate too slow

Steps to Reproduce

TODO

Version of Marlin Firmware

unknown

Printer model

custom

Electronics

unknown

Add-ons

unknown

Bed Leveling

None

Your Slicer

None

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

TODO

[printercnc]

i tried with latest marlin bugfix 2.1.x, it works great. Your tcpc branch has many errors, in addition to the g2/g3 migration error, there is also the problem of declaring spindle in the adv.h file. I have downloaded the latest version on your tcpc branch, reconfigured it, I will test it in the next few days to give you feedback. i use chip mega 2560 board ramps 1.4 for 5 axis machine, has limit switches for all 5 axis.

[DerAndere1]

What do you mean with tcpc branch? Do you use my Marlin2ForPipetBot branch ? With that branch I can enable SPINDLE_FEATURE without problems. Please provide your configs (Configuration.h, Configuration.adv) and the exact error message. You can attach files by putting them in a .zip archive. Then add a new comment below. While editing the comment, click on the button "Paste, drop or click to add file" below the comment.

[printercnc]

yes, I use the Marlin2ForPipetBot branch, which is the branch with tcpc kinematics

[printercnc]

These are the 3 files I have edited in there, In the pin ramps file, I edited the endstop part to add home points for axis a and c
FILE_CONFIG.zip

[printercnc]

two weeks ago, did you edit this issue, I don't know if it has anything to do with this g2/g3 x y z i j f move syntax (eg G3 F1800. I-54.51 J212.302 X93.326 Y-198.328) . I downloaded and reconfigured but haven't had time to test the motion on my cnc router.

[DerAndere1]

The change in commit d632ff3 was an attemt to fix an issue with erratic, fast moves when a G1 command involving only linear axes was followed by a G1 command without F parameter that involved rotational axes.

The compiltion error when SPINDLE_FEATURE and ABORT_ON_SOFTWARE_ENDSTOP were enabled is now fixed in branch Marlin2ForPipetBot with commit 00e49de.

[printercnc]

I downloaded your latest fix, compiled it, no more errors appear at the moment. I will test it on my cnc router.
I plan to make a handle through the Joystick port
on board ramps. Do you think it is necessary to add a separate handle to the firmware?

[printercnc]

PI3_chess-king.zip
This is the gcode sample I used to test the g2/g3 command. on the marlin_bgfix2.1.x branch works perfectly fine. On the Marlin2ForPipetBot tcpc branch they move but very slowly. I will send you the video as soon as possible.

[printercnc]

video.zip
When the axes move, the g0/g1 commands move very smoothly. When the g3 command comes to interpolate the arc, the two x y axes move slowly. I like your firmware because the axis movements are very smooth compared to the marlin_bugfix firmware.

[printercnc]

Am I annoying you by asking too many questions? I discovered an error that I cannot use g38 in the adv.h file if I use tcpc kinematics. I love your firmware, so I want to apply it to multi-axis CNC machines, or robotic arms. i know the marlin platform doesn't prioritize cnc work. If I bother you, then please try to fix the g2/g3 error.

[DerAndere1]

I appreciate any feedback. Please report as much issues as you can. I have a lack of time and I am not a "hardware guy", so I depend on testers and discussions like this to improve support for mills in Marlin. I will look into these bugs one at a time, whenever I have time to spare.

[DerAndere1]

I cherry-picked the two most recent change-sets affecting G2/G3 from MarlinFirmware/Marlin. One of the commits was called "Fix G2/G3 error in limit speed", so that might already fix the issue with G2/G3.

Please test the latest Marlin2ForPipetBot branch from today

Enble G38 with a non-cartesian machine at your own risk. It was never tested. Make sure that the rotational axes are in neutral (zero) position before you send G38: Probing currently can only work if your tool and probe is oriented in Z direction and when the table / printbed is oriented in the XY plane. Switch to tool 0 for probing. HOTEND_OFFSET for tool 0 must be 0.

To compile with G38_PROBE_TARGET, remove the following 2 lines from file Marlin/src/inc/SanityCheck.h before compilation:

https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.1.x/Marlin/src/inc/SanityCheck.h#L2518-L2519

  #elif !IS_CARTESIAN
    #error "G38_PROBE_TARGET requires a Cartesian machine."

[printercnc]

I just recompiled, and am excited to test this g2/g3 fix. We'll come back to this g38 topic once we're done with the g2/g3 fix. I will need some time to rebuild my multi-axis cnc router, with tests using high precision measuring tools. will then respond to you.

[printercnc]

The error is still not fixed, I took two pictures
Web comparisons and latest downloads. I'm confused and not sure if the download has to be updated.

[printercnc]

Previously discussed topic, I don't know if it can help?
MarlinFirmware#17348

[printercnc]

what a mess, marlin bugfix 2.1.x branch cannot connect to cura software like your branch.
g2/g3 motion video of marlin_bugfix2.1 branch
Uploading 1.zip…

[printercnc]

video when testing code with Marlin-Marlin2ForPipetBot branch, the response from the software is too strange
Uploading 2.zip…

[DerAndere1]

I can confirm that G2 is totaly broken in Marlin2ForPipetBot. On my machine, trajectories and feedrate are wrong, even when compiling for a cartesian machine (no special kinematics defined). It was working at some point,. Looks like some wrongly zero-initilized variable, but I cannot find it. The fr_mm_s varibale in the body of the function Planner::_populate_block shows correct values when executing G2 commands, so that is not the issue. I think the easiest and best way for me to fix this is to rebase onto current bugfix-2.1.x. Initially the new branch I plan to create will not support G49 or G43, it will allways be in TCPC mode. I have already rebased kinematics, quick_home and tool change. TOOLS and G10 is missing. It will take some weeks to have something ready for testing. Sorry for the inconvenience

[printercnc]

I feel a bit regretful if I have to go back to the beginning, the official branch on the marlin homepage, or the bugfix branch makes me not very confident about the part that creates pulses to make the axes move, the sound of the moving motors is not as smooth as the Marlin2ForPipetBot branch. your.
I'm not sure what effect tcpc or rtcp kinematics have, although on the 5-axis cnc machines I use they all have rtcp. The cam software I use all has the perfect gcode export feature. If we talk about compensation for misalignment on the spindle joints, adjusting the mechanical mechanism for accuracy will be much easier and better. With a controler for amateurs, I think what is needed on a device is the probe to find the xyz zero coordinate point. We don't always have to process with 5 axes, most of the time it will be 3 axes. Through that, as I mentioned the g38 issue in the adv.h file the other day, it is a perfect conversion feature for CNC 3D printing or CNC milling jobs. I'm on holiday, I brought a small test kit, eagerly waiting for you to fix the error to test, it's a pity to have to wait so long, haha

[HendrikJan-5D]

DerAndere1.
Did you see my message last week on GitLab ?

[printercnc]

I am building an additional handle for a cnc machine by using an Arduino nano to generate rotation pulses for the x y z axes. communicates with the motherboard via the RX TX interface. Everything on the handle is fine, but connecting to the motherboard is not possible. I don't know if the mega 2560 chip allows multiple PORT RX TX ports.
handle_video.zip

[printercnc]

I have completed the handle job version from a free source code, the problem is that I am testing the rx tx communication with the MKS GEN L board, the firmware allows using additional port 2. However, the central controller My heart is building on a multi axis cnc router which is a mega 2560 kit and ramps. I haven't figured out how to solve this problem yet. haha
test.zip

[printercnc]

I am trying to declare additional port 2 for board ramps, leaving two pins 16 17 for rx tx communication blank. Committing from marlin 2.x will allow the use of two ports, which I think is still not perfect.

[HendrikJan-5D]

a 2560 motherboard is an 8 bit version
i think you need to go to a 32 bit version for 2 usb connections.
See https://bigtree-tech.com/

[printercnc]

I have an MKS GEN L board using a 32 bit mega2560au chip, maybe I will test it, that is a temporary solution. with a mega 2560 8bit development kit that also has 3 ports for rx tx communication. pin 16 pin 17 is used for LCD control. Pin 18 pin 19 is used for z axis endstop. In addition, there are empty pins for i2c and spi communication. When I use the i2c pins to connect to the lcd screen, there will be free port rx tx pin 16 pin 17. Therefore, it will have to be used for two SERIAL_PORT, here it is probably an error in the compiler functions.

[HendrikJan-5D]

Looking at your compiler error list;
((#error “serial port 2 pin D16 and/or D17 conflicts with another pin on the board ))
Seems you have a problem in the pins file of your board.
D16 and D17 are in use there for another function
You have to clear and modify those first to use them as serial ports.

[printercnc]

That's right, however I can't figure out which lines are talking about the current function of those pins. 8bit chips cannot expand SERIAL_PORT without extensive firmware intervention. After carefully comparing ramps and MKS GEN L, I realized that my handle jod does not need the SERIAL_PORT extension. The above two types are the same, MKS GEN L is just RAMPS expanded with IO. I just need to check where the rx tx pin on the AUX1 of the MKS GEN L is connected to the MEGA 2560 chip. After that, just connect to RAMPS and you will be able to use it.

[printercnc]

I have connected handle job to board meg2560 + ramps via rx tx port. firmware marlin bugfix 2.1.x
I will use this to test DerAndere1's tcpc branch debugging
.zip

[printercnc]

DerAndere1
I discovered another error on your tcpc branch, the bugfix branch allows step to run at G0 max speed of 4500 mm/min, your branch is only 1000mm/min.
Board MKS GEN L 1.0
AXIS_STEPS_PER_UNIT 160
DRIVE A4988

[printercnc]

DerAndere1
Have you updated the fix yet?

[DerAndere1]

No progress yet. I was busy reviewing a friend's master thesis in my free time. Now that is done, but the upcoming weekends will be occupied with other duties. The code update is a major undertaking and will require a lot of efford. I can make only very slow progress after work. The fastest way to update is to search for the new features you need in all files of my fork and copy those changes to upstream marlin manually. rebasing with git will not be of great help because the commit history is not clean

[DerAndere1]

as a starting point, I have partially updated code in this branch: https://github.com/DerAndere1/Marlin/tree/penta_axis_kinematics . However, some pieces are still missing. Compile errors are expected at this stage. Also handling, of hotend offsets is certainly broken. It is really early untested WIP

[printercnc]

So you started rebuilding everything here before merging into the tcpc branch? I'm not in a hurry, I still use the main marlin to operate the cnc router. but I'm more excited about your branch, and I find using tcpc dynamics too complicated, which has its own benefits. Now that I know you're free, let's test out the added tools from a different angle.

[DerAndere1]

Current Marlin2ForPipetbot has diverged too much from Marlinfirmware/Marlin bugfix-2.1.x, so updating the code using git merge would be very cumbersome. That is why I sticked to my plan of creating the new branch. It may replace current Marlin2ForPipetbot as the default branch of my fork in the future. But as I said, https://github.com/DerAndere1/Marlin/tree/penta_axis_kinematics is not yet ready for hardware tests. If you manage to fix some of the remaining compile errors, you can speed things up by creating pull requests.

[printercnc]

do you mean this?
What is the deviation setting if the machine has many different extruders?

I think we should eliminate this hassle by just adding an M6 cnc machine tool replacement code. At this point, tool 0 can be a probe, CNC milling cutter or 3D printer extruder. Subsequent tools will be taken at pre-set coordinates. At this time, z0 will default to the printing table surface or CNC table surface, measuring the deviation of the following tools through comparison with probe number 0 (tool number 0)

Here is an example yt link for the problem
https://www.youtube.com/watch?v=00g7d2wuFAI

[DerAndere1]

Yes, HOTEND_OFFSET_X, HOTEND_OFFSET_Y, HOTEND_OFFSET_Z must be arrays with as many elements as you have tools. In Marlin, you can set hotend offsets at runtime using M218. In my fork I added an additional possibility to set the offsets for all tools (also non-extruder tools) with G10 as described in the Marlin2ForPipetBot README. When I have finished updating the new branch, Hotend offsets will be applied directly at toolchange.

Regarding the YT video you sent: If you want to do the same with Marlin, you can set up tool 0 as a dummy extruder by setting #define TEMP_SENSOR_0 0 or #define TEMP_SENSOR_0 999 and modifying your pins file so that a dummy value is assigned to E0 stepper pins. That way, tool 0 can be used for probing. I proposed a procedure for calibration of the hotend offsets using Marlin in the comments of this discussion: MarlinFirmware#26887.

[printercnc]

I really hate marlin's hotend feature, I don't know English, so using google translate will make it difficult for me to understand what you describe, I hope you don't get upset with me.
My way of doing it is like this, first in the adv file in the custom menu I add these lines, currently there are two tools

Then in the config.h file I turned on this line like this
#define Z_PROBE_END_SCRIPT "G54\nG92 Z52.5\n G53 G1 F1000 Z150"
z.52.5 is the distance of the fixed probe (mounted on the machine frame or table) compared to the z 0 coordinates of the machine G 53. (use z home max)
Then in the gcode.h file I added the M6 ​​code

in this line
#if HAS_CUTTER
static void M3_M4(const bool is_M4);
static void M5();
static void M6();
#endif
add M6 so

in file gcode.cpp
#if HAS_CUTTER
case 3: M3_M4(false); break;
case 4: M3_M4(true ); break;
case 5: M5(); break;
case 6: M6(); break;
add m6 like so

Continuing with the M3M5.cpp file, I added the function for M6

Now I just need to type M6T1, the machine will automatically run to the point to calculate T1 pre-specified in the adv.h file edited above to get the T1 tool to automatically run code G29 (with the condition that the scale is turned on). by a 3-point bed, and the coordinates of the first balance point are the coordinates of the fixed probe mentioned above)
I added everything to your Marlin2ForPipetBot branch firmware, ran the test suite and it worked, unfortunately the error Marlin2ForPipetBot branch g02/g03 moves too slow so I can't use it to run a cnc router yet

Maybe I don't understand the hotend feature clearly, but I feel it is too cumbersome and consumes the chip's processing memory. It is difficult to use industrial gcode export software to export gcode to these machines. Especially with the multi-axis motion feature of the firmware, it requires industrial code export software to support it.
I hope you and your colleagues will take advantage of my suggestions and build a simple tool exchange code that does not conflict with dirty firmware data. I'm not a programmer so I can't help you with this part.

[DerAndere1]

It is great to see that you found a solution to calibrate the tool length. It helps to discuss these things with you, as you seem to have experience with industrial CNC machines.

Your solution to introduce M6 is great. However, If I understand correctly, you use G29 to adjust for the tool length offset . This is not a solution for the general user. G29 is meant to be used for bed-leveling and only works properly on 3 axis machines. For a solution in Marlin that works with multi-axis machines, tool length offsets MUST be specified using the HOTEND_OFFSET_Z feature and M218 (or G10 L1 in my fork). Then, Marlin performs tool changes, including tool length compensation, directly when a tool change command is issued (Syntax: Tn where n is the tool index. No M6 needed)

Like you, I found the toolchanging code in Marlin very limiting and proposed changes that improve the situation (MarlinFirmware#26956). In addition, I added the command G10 L1 to my fork to provide a method for setting tool length offsets that is comptible with the reference standard (which is LinuxCNC). These changes are already integrated into https://github.com/DerAndere1/Marlin/tree/penta_axis_kinematics.

In the coming weeks I will try to test the branch https://github.com/DerAndere1/Marlin/tree/penta_axis_kinematics. Once it works roughly as expected, I will let you know.

In the meantime, I invite you to make yourself familiar with the HOTEND_OFFSET feature and the tool changing mechanisms supported by Marlin. To make use of my improved toolchange code which is intended to work with tool carousels or tool magazines, you will have to use the branch https://github.com/DerAndere1/Marlin/tree/penta_axis_kinematics, enable the option SWITCHING_TOOLHEAD and set the related options in Configuration.h. The new options are:

// Safe toolchange start Z position.
//#define SAFE_TOOLCHANGE_START_Z

//#define SWITCHING_TOOLHEAD_Z_POS        100         // (mm) Z position of the toolhead dock.
                                                      // Leave disabled if bed can move in Z direction

//#define SWITCHING_TOOLHEAD_Z_CLEAR       60         // (mm) Minimum distance from dock along Z for unobstructed X axis if the tools are placed onto the dock in Z direction

Note: HOTEND_OFFSET_Z values, set with M218, are the opposite of tool length. E.g. if tool 0 length is 0mm and tool 1 length is 20 mm, you need `#define HOTEND_OFFSET_Z {0, -20} (set via G-code with M218 T1 Z-20)
In my new branch you can set tool length directly (in this example, you would use G10 L1 P1 Z20)

Unfortunatelly, the industry failed to compose a modern international Gcode standard that encompasses automtic tool changers, tool setters and multi-axis features. Marlin has its own method for calibrating the tool length offset, which is G425. I invite you to study my proposal (MarlinFirmware#26887) in depth. It is the best documentation of how to use that Gcode I can find so far. testing and feedback is highly appreciated. If you want to trigger G425 upon each toolchange, I suggest to experiment with the following features in Configuration.adv:
#define EVENT_GCODE_TOOLCHANGE_T1 "G425 T1" and #define EVENT_GCODE_TOOLCHANGE_T2 "G425 T2"

If you want to share code, please copy the code block in text form and enclose it in tripple backticks (```) as described here: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-and-highlighting-code-blocks

[printercnc]

At that time, I used the old 2.0 firmware, then updated it to your tcpc branch to test, so the configuration.h file was just a command form.
( * Commands to execute at the end of G29 probing.

• Useful to retract or move the Z probe out of the way.
  */
  #define Z_PROBE_END_SCRIPT "G54\nG92 Z52.5\n G53 G1 F1000 Z150"
  )
  With that comment, I think that command line is only for g29, I thought I would use it for your tcpc branch, then instead of using the g29 command, use the g38.2 command, but unfortunately, your tcpc branch at that time There was a compilation error with the G38 Probe Target, so I haven't had time to test it with g38.2

g29 is not for measuring tool length, with g29 as I understand it recognizes where the Z0 points are compared to Zmax.
The way I do it, when I take tool number 1 (cnc milling cutter), I bring it to Oxyzabc 0 point, which is the coordinates of the workpiece to be machined, matching the coordinates on the CAM software. I set this Oxyzabc 0 point to 0 with command g92. xyzabc ->0 from the LCD screen and let it auto save to G54. Then I let this tool auto measure with the probe switch fixed to the frame or table as described previously, with command g29. So this is not the tool length, but the distance from the Z MAX point to this standard reference tool tip (or from the Zpos min point to the reference tool tip). This reference tool always has a constant distance from Zmax point to the tool tip. When I take tool 2, with the command T2M6 (M6 is a macro code added to execute a series of commands without having to call it many times in GCODE when the machine is machining) the machine will automatically run to the coordinate point where the probe is attached to operate. Compare how much longer or shorter this tool is than the reference tool, then Marlin compensates to continue running the GCODE program with this tool. i think it will also work fine with g38.2 command.

I'm so tired of testing Marlin's features, they really have too many bugs, Marlin developers just add hundreds of things and then forget about basic dynamic testing. so I'm going to pause testing HOTEND.

With the G425 command and the G10 part you rely on the linus_cnc platform, I feel that linus_cnc is based on the cnc machine platform of HAAS products manufactured in the US. I find it difficult to use compared to the T0M6 code of German or Japanese-made cnc machines.

I think just letting the firmware understand what the distance from the Zmax point to the tool tip is and where the Oxyzabc 0 point is located is easy for building tcpc kinematics. I will discuss this tcpc part with you tomorrow.

I plan to include it here https://github.com/DerAndere1/Marlin/tree/penta_axis_kinematics then send it back to you

[DerAndere1]

I force-pushed several changes to https://github.com/DerAndere1/Marlin/tree/penta_axis_kinematics in the last days. If you pull a fresh copy now, you should have a good starting point for your tests. I also found that the delta varliable was uninitialized and fixed that. I quickly sent a G2 command and it seemed to work. Note that with this branch, TCPC mode is currently always on, as if G43.4 was issued.
HOTEND_OFFSET_Z... is Marlins terminology for the tool table. G29 is documented here: https://marlinfw.org/docs/gcode/G029.html .

[printercnc]

M6_Marlin-2.0.x.zip

Here is the original m6 code file added and tested in practice and it works fine. I share this way because I actually don't know English, I almost don't understand the instructions in the links you sent to google translate.

[printercnc]

Now let's discuss more about rtcp before, tomorrow I will discuss more about g10l1 and g34h tool height offset.

If the mechanical model is accurate, the machining center will be as shown. In reality, we have mechanical models that have error deviations with a tolerance of 1/1000, so Dy deviation is 0. We only have Dz deviation left, I have two ways to solve the problem.
_ Solved by mechanical jig based on the deviation Dz provided by the model manufacturer, we machine the jig surface using the correct deviation Dz with an error of 1/1000. So the center of rotation coincides with the model on the drawing, then on the Gcode CAM export software I just need to select the machining center on the software that coincides with this center of the cnc machine.
_ Solve with 3D drawings of mechanical models with Dy and Dz degrees, then put them into CAM software to perform machining simulation operations, we call it post-processor.
link is an example of this problem, this ensures that the machine will work correctly, without causing collision errors.
https://www.youtube.com/watch?v=qhEdmKSCf1Q&list=PL7Y9ghGDianLATfEW-81NhvcyIjyw89ut
You see, with CAM software we don't need rtcp for anything, the important thing is whether the kinematic control allows the xyzabc axes to move synchronously with each other or not.

So what are the advantages of tcpc for regular users? That is to compensate for amateur-made Dy Dz deviations, it does not guarantee an error of 1/1000. What I want is that when selecting the tcpc option, reporting the offsets, the machine will automatically calculate and compensate for the offsets correctly when we enter the Gcode without having to call the G43.4 kinematic command code like this.
G43.4
G1 B45
G1 B0
G49
G1 X100
G43.4
G1 C360
G1 C0
G1 B45 C360
G1 B0 C0
G49

That's why I think we have to use codes T and M6 to call the tool and measure the distance from the Zmax point to the tool's starting point. We don't need to declare the offset for each tool, because we measure will not be accurate.
we will have diy cnc machines like this, https://www.youtube.com/watch?v=f4ybGiXNN24
To measure the point 'Z0 working plane' we need a contact probe to measure. This tool will then be referenced with the probe to determine how far the tool tip is from the Zmax point, how much is the deviation from the 'Z0 working plane' face to compensate for other tools after being replaced. enter. We don't even need T code or M6 code to call the tool, we just need a script to run g38.2
https://www.youtube.com/watch?v=-2jFvlvu0co

[DerAndere1]

Thank you for sharing your thoughts and the code. It reminds that I have to test probing (G38, G38.2) and workspace offsets (G54, G55...) in the new branch. The sanity check that has to be removed to test PROBE_TARGET (G38.2) on multi-axis machines is here:

Marlin/Marlin/src/inc/SanityCheck.h

Lines 2570 to 2571 in db95270

	#elif !IS_CARTESIAN
	#error "G38_PROBE_TARGET requires a Cartesian machine."

[printercnc]

I'm struggling with the delta machine, so now I have free time to carefully read the g10l1 syntax on linus. https://linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G10-L1
-G10 L1 P1 Z1.5 (set tool 1 Z offset from machine origin to 1.5)

For example, with that syntax, I have to understand that tool number 1 is located 1.5 away from tool number 0. Knife number 0 is the knife with length equal to 0 and coincides with the center of Oxyz = 0 or the center of the machine (3D printer). This is completely reasonable for a 3D printer, however you can use the M6 ​​code I shared to have the machine automatically recognize this offset through the touch-probes, all of which are connected to the Zmin pin.
We can use HOTEND to create tool positions at x - y coordinates with coordinates defined with the g53 machine origin. The z deviation will be measured by probe and saved to working coordinates G54

[printercnc]

Is there any way to fix this warning "G38_PROBE_TARGET requires a Cartesian machine." ? I think all cnc machines, whether or not they have special kinematics, before the machine works with Gcode, the moving axes need to move to a position away from the working space. z is up to Zmax, xmin, ymin (can be xmax ymax). The A B C axes also need to be located parallel or perpendicular to the X Y Z axes. For example, with TRT kinematics, the inclined crane A B is parallel to the X Y axis. In the home position, the rotation axis A B must make the C axis parallel. parallel to axis C, rotary table surface C is perpendicular to axis C parallel to X Y axis.

We can call the working point the center (0,0) of the ROTARY table C and Z0 is on the surface of the turntable. If we choose to save this point in G54 it will be G54 X0 Y0 Z0 A0 C0, if we choose to save it in G53 then the distance from the home point XY to this point needs to be measured with a standard center finder tool,
(I don't know if Marlin allows this declaration, let the default working point always be this point, then we don't need to care about other workspace coordinates G54 G55..)
Then, to refer to the tool length, we only need to g38 to have the machine automatically run to the built-in touch_probe coordinate point to know how far the current tool center peak is from the Z0 plane of the turntable, then subtract it automatically. Special kinematics will become active and become active only after this measurement.
This idea of ​​mine is to help the kinematics part not have to be calculated too much, leading to errors. If we assume we have the center of the machine at point G53 I described above, but the working point G54 does not coincide with this center, it is located In the intermediate space beyond the turntable, the kinematics will certainly require more orbital compensation calculations.
I have designed a pendant set based on the discussion here, it works well with all 5 axes, based on the MKS_GENL board (with this board when using the EXP2 port I cannot connect and use an additional USB port to connect to the part). software on your computer) with this pendant set you will easily operate the touch_probe to measure positions. However, to get accurate coordinates, we need to home first, then rotate MPG to reach the locations that need to be measured accurately. One bad thing is that Marlin does not display the exact coordinates of 1/1000 on the LCD screen. I have to go to the move axis section to know exactly where the machine is located.
https://forum.v1e.com/t/marlin-pendant/32245/6

However, it fails with the encoder over 20 pulses, I don't know why

[DerAndere1]

To remove the error "G38_PROBE_TARGET requires a Cartesian machine", you have to delete the two lines of code I mentioned in my last comment here: #72 (comment)

In case you have EXTRUDERS 0, you also need this change which I just pushed a minute ago:
20b461f