Eliminate preview fails (was Use G54 for Z-offset) about probe-screen-ng

[kiall]

I suspect this was done because it allowed the probe screen to to determine it's own reference plane using both a touch probe and tool setter.

Here's some factors I think will affect how this can be done:

• Users with no fixed length tools (like me!) don't have a consistent position for the probe or any reference tools available. Every time it's inserted, it will be in a different position.
• Many users don't have a fancy tool setter - they use a simple electrical contact pad and a wire clipped to the tool.
• Many users don't have the toolsetter bolted down to the table - meaning it can move between uses.

[freisei]

* Users with no fixed length tools (like me!) don't have a consistent position for the probe or any reference tools available. 

Every time it's inserted, it will be in a different position.

thats no problem, the probe-lenght and the tool-setter-height can be measured every time when probe-lenght changes with the same procedure (like you do now)

* Many users don't have a fancy tool setter - they use a simple electrical contact pad and a wire clipped to the tool.

Does the type or precision of toolsetter affect psng-code in any way?

* Many users don't have the toolsetter bolted down to the table - meaning it can move between uses.

even no problem. I have the same use-case.

I am already working with an modified version that uses G54 - its not tested enough and i didnt think about every use-case but i can make a branch if the files-cleanup branch is merged.

[freisei]

If a user wants use persistent tool-lenght-offset for some tools, this user will have an persistent-lenght probe. Otherwise it makes no sense.

[kiall]

thats no problem, the probe-lenght and the tool-setter-height can be measured every time when probe-length changes with the same procedure (like you do now)

To me, that seems like a problem? If you don't know exactly where the toolsetter is or exactly where the probe is, you have no reference available to do things the right way?

Maybe I'm just not thinking of a way to make it work and you have some ideas :D

Does the type or precision of toolsetter affect psng-code in any way?

No, this was just in relation to having things move around and not be consistent positions etc :)

[freisei]

To me, that seems like a problem? If you don't know exactly where the toolsetter is or exactly where the probe is, you have no reference available to do things the right way?

For persistent-tool-lenghts the probe-lenght must be fix too.

The TS-Height can vary it just must be measured after altering. (Same as versers-behavior)

persistent-lenght-tool-procedure:
We have one position: Probe-To-TS (TS-Height) - this is our reference-height.
Then we measure the tool offset from probe (and safe that to tool-table)
So with active TLO we have Z=0 set to tool-end, when a fixed-lenght tool is inserted.
G54 must be set to match the workpiece. (which is currently badly done by adding the workpiece-height to TLO)

non-persistent-lenght-tool-procedure:
We measure the position: Probe-To-TS (TS-Height) - this is our reference-height.
Then we measure the tool offset from probe (and safe that to tool-table)
So with active TLO we have Z=0 set to tool-end, when a fixed-lenght tool is inserted.
G54 must be set to match the workpiece.

[alkabal]

Hi

In my fork i have change the whole logic for saving offset and G10

Original component use the blockheight for tool offset in the tooltable ???

I have dedicated the probe down function for table probing, after that you can probe the tool setter and the value is automatically updated and saved.
With this methode now i save tool offset without including the blockheight
blockheight is now a current coordinate offset

[kiall]

Reopening - #52 fixed some of the issue, but defiantly not all of it.

[kiall]

With the changes in #62 - the preview will now always be correct - i.e. the preview fail is fixed 🥳