Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eliminate preview fails (was Use G54 for Z-offset) #2

Closed
freisei opened this issue Dec 1, 2020 · 8 comments · Fixed by #62
Closed

Eliminate preview fails (was Use G54 for Z-offset) #2

freisei opened this issue Dec 1, 2020 · 8 comments · Fixed by #62

Comments

@freisei
Copy link
Contributor

freisei commented Dec 1, 2020

I want to eliminate preview-fails.
In current code, we use only the tool-offset (TLO-Z) to set the height of the tool to the height of the workpiece. I think that is a kind of hack.

Better would be to use correctly the workpiece-offset (G54 etc.) AND the tool-offset
(btw: this is the normal way)

If we do this way, probe-screen can be enhanced with

  • persistent-tool-offsets for a defined range of tools (e.g. T50-T99 is persistent, T1-T49 is measured every time)
  • persistent-tool-measurement-button

I think many users have only a range of tools which must be measured every time and a set of tools which has the same length for a longer time.

@kiall
Copy link
Contributor

kiall commented Dec 8, 2020

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
Copy link
Contributor Author

freisei commented Dec 8, 2020

* 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
Copy link
Contributor Author

freisei commented Dec 8, 2020

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
Copy link
Contributor

kiall commented Dec 8, 2020

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
Copy link
Contributor Author

freisei commented Dec 8, 2020

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
Copy link
Contributor

alkabal commented Dec 23, 2020

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 kiall changed the title Use G54 for Z-offset Eliminate preview fails (was Use G54 for Z-offset) Dec 28, 2020
@kiall kiall closed this as completed in 3ebcdcf Jan 10, 2021
@kiall
Copy link
Contributor

kiall commented Jan 10, 2021

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

@kiall kiall reopened this Jan 10, 2021
kiall added a commit that referenced this issue Jan 10, 2021
To my knoweledge, this resolves all issue where the Preview does
not match the toolpath.

Fixes #2
@kiall
Copy link
Contributor

kiall commented Jan 10, 2021

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

@kiall kiall closed this as completed in #62 Jan 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants