Five-Axis RTCP Features: G43.4 and G43.5 Equivalents in LinuxCNC

Hello everyone,I am a new LinuxCNC user and developer. This time, I would like to use LinuxCNC in combination with my cutting simulation process. I have encountered some problems and would like to know if there are any known solutions in LinuxCNC. If not, I am interested in developing features similar to G43.4 and G43.5.Before we get into the details, let me provide some context. I am running LinuxCNC 2.9.4 on Debian 12 with PREEMPT_RT. Please note that for my simulation process, real-time (RT) capability is not a strict requirement. My simulation uses the configuration from , which matches the machine type I need.Here is my understanding of the five-axis xyzab-tdr support:
The key is the toolpath (TP) transformation. Five-axis machines are different because they require transforming the workspace coordinates to real joint positions, which involves both forward and inverse kinematics. The xyzab-tdr configuration provides these transformations. The main parameters for these transformations are seven in total: , , , , , , and . The , , , , , and  define the machine’s geometry, while  functions similarly to Fanuc's G43.4 RTCP (Rotating Tool Center Point) tool compensation.In RTCP, G-code is typically provided in two forms:Fanuc-like: Siemens-like:My questions are:

1. In Fanuc, G43.4 is modal. Does LinuxCNC use the TP transformation as a modal mode as well? In other words, when using five-axis TP, is G43 equivalent to G43.4 in LinuxCNC?
2. The IJK parameters are used for Freeform Surface toolpaths. Does the G-code parser in LinuxCNC support IJK-style input?

Thank you in advance for your help and insights!

Thank you for your answer!

Based on your reply, I understand that G43 tool length compensation depends entirely on which kinematic mode is active. I have implemented a conversion from vector format NC (IJK) to XYZAB for my machine, and it seems to work. However, I am concerned whether a simple conversion might misinterpret the intent of the CAM output, or if these two formats (IJK and AB) are truly equivalent and interchangeable.

Here is the logic of my transfer function:

def ijk_to_ab(self, i, j, k):
norm = math.sqrt(i**2 + j**2 + k**2)
i, j, k = i/norm, j/norm, k/norm

a_rad = math.atan2(j, k)
a_deg = math.degrees(a_rad)

b_rad = math.atan2(-i, math.sqrt(j**2 + k**2))
b_deg = math.degrees(b_rad)

return round(a_deg, 6), round(b_deg, 6)

I have two more questions:

Are there any problems with my transfer function (ijk_to_ab)? Although it works in practice, I am worried that a direct conversion might not fully capture all the intent or precision from the CAM output.
If I plan to extend the RS274 module to support vector input, which vector format would be better to implement: the FANUC-style IJK (G43.5) or the SIEMENS-style A3/B3/C3? Are there advantages or disadvantages to either format, especially regarding compatibility and ease of parsing?
Thank you again for your help and suggestions!