[LinuxCNC/linuxcnc Issue#233] 5 axis wrong preview with W axis

#1 – luzpaz 于 2023-06-26

Is this still reproducible for you @grandixximo ?

#2 – grandixximo 于 2023-06-27

It appears that the situation has worsened as the vismatch is now also “incorrect.” The concept of the 5-axis system in LinuxCNC seems to have deviated from what I was accustomed to. Currently, there is an example code where W is used for drilling purposes on version 2.9. However, I have yet to come across any commercial or free computer-aided manufacturing (CAM) software that handles 5-axis machining in this manner. And in version 2.10 the situation is even worse as now W is previewed as parallel to Z, which is not.

!image

My understanding of W was that it represented tool length. In the toolpaths generated by CAM software for 5-axis XYZBC movements, tool length is accounted for by loading the appropriate W axis offset from the tool table. Then, W is moved to W0 to accurately compensate for the tool length. This adjustment can be easily incorporated into most post-processors.

This method resembles how tool lengths are managed on a standard 3-axis mill that utilizes the tool table’s Z axis offset. However, in the case of 5-axis machining, offsetting Z would not suffice since the tool’s length may not align parallel to Z, depending on the orientations of the B and C axes. That’s why W moves parallel to the last pivot direction – to handle tool length. Similar to how G43 and Z offsets function for 3-axis mills, where tool previews remain unaffected by changes in tool length, W effectively makes the tools longer, in my opinion. Although I understand that it also affects joint movements (just like Z tool offset for 3-axis mills), the question remains: should the plot display the toolpath of the center tip of the tool or not?

If you are inclined to believe that it shouldn’t, let’s consider a scenario where the same part is worked on using two tools of different lengths. How should the preview and plot be presented in this case? In my opinion, the correct response would be to display the toolpath XYZ positions that correspond to the form being milled, without incorporating any variations in tool length (W). If you still disagree, I would appreciate a detailed explanation of your reasoning.

I understand that there have been modifications since I last examined this issue, but it seems they have been made in the wrong direction, in my opinion. I would be interested to hear the developers’ thoughts on this matter.

!image
!image
Try this in MDI
“
T100 M6
G0B45C45
G43
G49
“
these example codes makes the motor position “teleport” to another position without any kind of acceleration or velocity, it’s an instant teleportation, this is really bad in my opinion, when you have actual motors connected that will not be fun to watch.

#3 – Sigma1912 于 2023-06-27

As I understand it, the use of the W word for motion relative to the tool Z axis is a feature incorporated in the bridgemill kinematic and not a bug in linuxcnc.

Possible background:
I’m no expert but apparently there used to be (maybe still are?) machines where UVW command motion relative to XYZ respectively. Personally I have not come across a machine like that, the controllers I know use some form of ’tilted work plane’ (eg fanuc G68.2). IMHO since the merger of switchable kinematics it would be better to use a dedicated tool kinematics and a tilted work plane feature.

#4 – grandixximo 于 2023-06-27

To fix the use of ABCUVW in axis display, there should be a way to define what the extra axis are supposed to represent in the INI file for [DISPLAY], many users may be accustomed to different uses of these words, it would be neat to be able to customize them.
I do agree about dedicated tool kinematics, you could have a kinematics to change tool length where tool length is motion less, switch to that kinematic to change length without motion, and switch back still without motion, but now having a new tool length, and all motion would be centered on the new tip, if that could be directly implemented in G43 G49 that would be amazing.
So far I’ve been using W axis, as it was serving a similar function but it was doing it with actual acceleration and motion, so the machine wouldn’t suddently try to teleport on me, I’ve also been using switchable kinematics and that simplified it because now I can switch to a kin that does not use W to reset the tool length, but now that I think about it direct manipulation of a tool length variable would be quicker, as long as the machine doesn’t try to “teleport”.

#5 – Sigma1912 于 2023-06-27

I gather that the opengl code used in vismach and preview is no longer up to date with current developments in 3D rendering and may need to be updated/replaced at some time.
Also note that the preview behavior seems to have changed since version 2.8 where uvw moves were rotated by ABC rotations but this does not seem to be the case since version 2.9. Now it’s parallel to XYZ regardless of ABC rotation. One used to be able to customize the behavior somewhat by changing the order of the axis letters in the [Display] section but I could not get the rotation working.
I have worked on a sim config for a machine with a rotating nutating head that included IDENTITY, TCP and TOOL kinematics and also a crude remap for tilted work plane which I posted on the forum a little while ago.
Feedback was literally zero.

#6 – grandixximo 于 2023-06-27

> I gather that the opengl code used in vismach and preview is no longer up to date with current developments in 3D rendering and may need to be updated/replaced at some time. Also note that the preview behavior seems to have changed since version 2.8 where uvw moves were rotated by ABC rotations but this does not seem to be the case since version 2.9. Now it’s parallel to XYZ regardless of ABC rotation. One used to be able to customize the behavior somewhat by changing the order of the axis letters in the [Display] section but I could not get the rotation working. I have worked on a sim config for a machine with a rotating nutating head that included IDENTITY, TCP and TOOL kinematics and also a crude remap for tilted work plane which I posted on the forum a little while ago. Feedback was literally zero.

Please post here the link.
I think the proper implementation would require a Tool Length column in the tool table, as it should not be axis related, need see what the devs think.

#7 – Sigma1912 于 2023-06-27

https://forum.linuxcnc.org/show-your-stuff/49103-kinematic-model-for-a-5axis-mill-with-universal-45-nutating-head#271334
Documentation is also provided in the zip folder.

#8 – grandixximo 于 2023-06-27

When you say TOOL kinematics work, what do yuou mean specifically?

#9 – Sigma1912 于 2023-06-27

When in Tool kinematic mode XYZ motion commands are executed in the current tool coordinate system. So a Z move should move the tool along its rotational axis (eg for drilling) whatever the tool orientation.
Motivation here was to create a sim that has TCP (where the CAM does the calcurations) and TOOL kinematics where required CAM functionality is done in LinuxCNC so prismatic machining with tool side rotation can be done without the need of a CAM system. The operator can easily program ,say a circular pocket in any tool orientation directly on the machine.
Note that ’tilted work plane’ functionality comes ‘for free’ on machines with table rotation since here the Z axis remains parallel to the tool rotional axis. So this is only of interest on machines with tool side rotation like the featured rotating/nutating head or also the ‘bridgemill’ configuration.

#10 – Sigma1912 于 2023-06-27

I see this more of an exploration of using ‘Tilted Work Plane’ functionality. Further work would include:
– Since the feature requires basic CAM functionality to orient the tool to the requested work plane there needs to be a machine specific model to calculate the joint positions. Ideally this would be done automatically using a config file that then builds the model automaticcally.
– The Python remap would need a lot more testing and debugging. In the end this would really need to be implemented in the interpreter rather than a python remap.
– To make things clearer to the user an augmented preview would be preferable. I implemented some of my ideas in the custom vismach patch but it would be much better to actually fuse the gcode preview and the vismach model into one.

#11 – grandixximo 于 2023-06-27

> When in Tool kinematic mode XYZ motion commands are executed in the current tool coordinate system. So a Z move should move the tool along its rotational axis (eg for drilling) whatever the tool orientation. Motivation here was to create a sim that has TCP (where the CAM does the calcurations) and TOOL kinematics where required CAM functionality is done in LinuxCNC so prismatic machining with tool side rotation can be done without the need of a CAM system. The operator can easily program ,say a circular pocket in any tool orientation directly on the machine. Note that ’tilted work plane’ functionality comes ‘for free’ on machines with table rotation since here the Z axis remains parallel to the tool rotional axis. So this is only of interest on machines with tool side rotation like the featured rotating/nutating head or also the ‘bridgemill’ configuration.

Had to read it a couple of times, but I think I understand, you switch between TOOL kins and TCP kins with G12.1 Pxx correct?

#12 – grandixximo 于 2023-06-27

To return on topic yes, original post was about the 5axis mill preview not being correctly represented, there are many paths devs could take to fix that.
But looking at the 5axis bridgemill configuration on 2.10 it’s become something that cannot help the user understand 5 axis machining on a machine like that, and the “teleporting” is dangerous.

#13 – andypugh 于 2023-06-27

> My understanding of W was that it represented tool length. In the toolpaths generated by CAM software for 5-axis XYZBC movements, tool length is accounted for by loading the appropriate W axis offset from the tool table.

This can be done, but isn’t necessarily correct.

A common interpretation is for XYZ to represent a position in cartesian space, and then A and B to represent rotations about that point that determine the tool direction.

In some interpretations UVW are then moves in a reference frame aligned with the tool axis, so that W would be a drilling move along the tool axis, and U and V would set a position in that plane (Where do U and V point? This would be implementation specific. (ie whatever the kinematics module in use chooses to do)

Tool length is not generally the W axis but is, rather an offset along the tool axis (which is parallel to W). This is often passed into the kinematics on a HAL pin. (And can actually be pulled out of any column of the tool table, depending on the whim of the system integrator)

#14 – Sigma1912 于 2023-06-27

> switch between TOOL kins and TCP kins with G12.1 Pxx correct?

Kinematic switching is done using M428, M429 and M430.

#15 – grandixximo 于 2023-06-28

> > My understanding of W was that it represented tool length. In the toolpaths generated by CAM software for 5-axis XYZBC movements, tool length is accounted for by loading the appropriate W axis offset from the tool table.
>
> This can be done, but isn’t necessarily correct.
>
> A common interpretation is for XYZ to represent a position in cartesian space, and then A and B to represent rotations about that point that determine the tool direction.
>
> In some interpretations UVW are then moves in a reference frame aligned with the tool axis, so that W would be a drilling move along the tool axis, and U and V would set a position in that plane (Where do U and V point? This would be implementation specific. (ie whatever the kinematics module in use chooses to do)
>
> Tool length is not generally the W axis but is, rather an offset along the tool axis (which is parallel to W). This is often passed into the kinematics on a HAL pin. (And can actually be pulled out of any column of the tool table, depending on the whim of the system integrator)

How should tool length be managed? You think current 5axis bridgemill is a correct representation?

TLOISALONG_W = 1

I always took this as meaning W is TLO, but I guess they are just parallel then…

https://sourceforge.net/p/emc/mailman/message/18716820/

I’m not the only one thinking this way, but I agree it’s not how things are done outside of LinuxCNC.