rendering of the tool faces

[grandixximo]

@alex-pres See the picture, this happens in the vismach 5axis configuration, if you run the gcode, depending on how you orient the view, there is one face of the tool that renders as transparent, or even deletes other parts of the tool, the face itself should not be visibly; but what is in front of it should be, I think its is being like actively deleted when not in view, and that somehow also deletes what's supposed to be in front of it? just a guess...

[alex-pres]

I will fix that , looks like a rotated tool cut by plane .

However, that reminds me another question - are we interested to have "replay" in the preview? Where tool moves by traj like in simulator? if yes, for 4+ axis milling, I will add some optional raw data returned from C++ to Python with ProgramGeomerty. It will allow those who interested implement this and may be I will also do it in next PR.

[grandixximo]

Simulation is a nice to have feature, the preview is kind of the simulation, but for multi axis you don't really see how the tool gets oriented, even when the line look right, the tool might swing the wrong way...

[alex-pres]

Order of vertices was incorrect, internal faces were drawn over external faces if explain it in simple words.

[Sigma1912]

My big dream is to have the preview rotate the path segments with the machine geometry. A start was made with the '!' in the [DISPLAY] GEOMETRY entry but rotational axis offsets have proven to be a challenge.
https://linuxcnc.org/docs/html/config/ini-config.html#sub:ini:sec:display

[alex-pres]

My big dream is to have the preview rotate the path segments with the machine geometry. A start was made with the '!' in the [DISPLAY] GEOMETRY entry but rotational axis offsets have proven to be a challenge. https://linuxcnc.org/docs/html/config/ini-config.html#sub:ini:sec:display

Do you have any example where it fails ? I never worked on 4+ axis so have no experience how correct LinuxCNC renderring works for this. Existing tests are green.

[andypugh]

My big dream is to have the preview rotate the path segments with the machine geometry. A start was made with the '!' in the [DISPLAY] GEOMETRY entry but rotational axis offsets have proven to be a challenge. https://linuxcnc.org/docs/html/config/ini-config.html#sub:ini:sec:display

I thought that that could be made to work by the order in which the axes are defined in the [GEOMETRY] ?

I made it work here (unless I am misunderstanding your question)
https://forum.linuxcnc.org/20-g-code/27169-g-code-to-engrave-numbers-on-cylinders

[alex-pres]

My big dream is to have the preview rotate the path segments with the machine geometry. A start was made with the '!' in the [DISPLAY] GEOMETRY entry but rotational axis offsets have proven to be a challenge. https://linuxcnc.org/docs/html/config/ini-config.html#sub:ini:sec:display

I thought that that could be made to work by the order in which the axes are defined in the [GEOMETRY] ?

I made it work here (unless I am misunderstanding your question) https://forum.linuxcnc.org/20-g-code/27169-g-code-to-engrave-numbers-on-cylinders

Just verified it still works correctly in last version

Used sim/axis/axis_9axis.ini with patched GEOMETRY = !ABCXYZYVW

Rotational axis must have ! before letter in the GEOMETRY string and it seems to works fine.

[Sigma1912]

Rotational axis must have ! before letter in the GEOMETRY string and it seems to works fine.

Yes, it works but it's not so easy to setup and it is not the whole picture:

Experimental: If the exclamation mark (!) character is included in the GEOMETRY string, display points for A, B, C rotations respect the X, Y, Z offsets set by G5x, G92 codes. Example: Using GEOMETRY = !CXZ for a machine with [TRAJ]COORDINATES=XZC. This provision applies for liveplots only — G-code previews should be done with zero G5x, G92 offsets. This can be facilitated by setting offsets in programs only when task is running as indicated by #<_task> == 1. If nonzero offsets exist at startup due to persistence, offsets should be zeroed and preview reloaded.

Which basically means that it is not possible to just load a multi axis program and see the correct preview because it does not take the geometric offsets into account.
My dream is for the preview to read the code and actually show the correct tool path for the specific machine geometry. For this it would need to have a geometric model of the machine just like what you get when you run the code in a vismach model.

[alex-pres]

Rotational axis must have ! before letter in the GEOMETRY string and it seems to works fine.

Yes, it works but it's not so easy to setup and it is not the whole picture:

Experimental: If the exclamation mark (!) character is included in the GEOMETRY string, display points for A, B, C rotations respect the X, Y, Z offsets set by G5x, G92 codes. Example: Using GEOMETRY = !CXZ for a machine with [TRAJ]COORDINATES=XZC. This provision applies for liveplots only — G-code previews should be done with zero G5x, G92 offsets. This can be facilitated by setting offsets in programs only when task is running as indicated by #<_task> == 1. If nonzero offsets exist at startup due to persistence, offsets should be zeroed and preview reloaded.

Which basically means that it is not possible to just load a multi axis program and see the correct preview because it does not take the geometric offsets into account. My dream is for the preview to read the code and actually show the correct tool path for the specific machine geometry. For this it would need to have a geometric model of the machine just like what you get when you run the code in a vismach model.

To be honest I still dont understand. Which exactly offsets does not it take? It should.

[ I am not sure about rotating spindle head here but it should too, generally that is just another geometry transformation ]

BTW, it is easy to modify GEOMETRY string from python rendering code if desired. It is literally last variable that C++ rendering code asks from the Python, so there is a place for customisation if it necessary.

[grandixximo]

I'm fixing some of this stuff, at least for 5axis, most of it will match, If you see my original picture, those moves that look vertical in axis, they are actually W moves, which are supposed to be moving a quill that extends and retracts out of the spindle, and the spindle is oriented, so they are actually completely different in how vismach and axis shows them. vismach is always right if you hook it up like the machine, 5axis vismach does not have the quill, but the kins do, I am adding it, and doing some test gocdes there, will push something tomorrow.
The other problem is having g12.1 or other kinematics switching, currently we have a sudden jump of position, because we go from axis to joint world, but we are still moving and displaying them as if they were axis, as if they were moving the tool from the tip, which they are not, in vismach nothing moves on a kin's switch from world to identity (joint), you'd have to do what vismach does and having the geometries in axis UI as well, or something derived from the kinematics, and kinematics switch aware.

[alex-pres]

I am afraid I am not such brave to start it. It probably will need fresh look to implement it right way.

I hope the converted code will be good base to do it, it matches what have been done in Python as much as possible and optimised.

One can take list of moves (may be some move "kind" should be added for g12.1 etc) and build another preview from this.