-
Notifications
You must be signed in to change notification settings - Fork 18
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
Comments
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:
|
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)
Does the type or precision of toolsetter affect psng-code in any way?
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. |
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. |
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
No, this was just in relation to having things move around and not be consistent positions etc :) |
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: non-persistent-lenght-tool-procedure: |
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. |
Reopening - #52 fixed some of the issue, but defiantly not all of it. |
To my knoweledge, this resolves all issue where the Preview does not match the toolpath. Fixes #2
With the changes in #62 - the preview will now always be correct - i.e. the preview fail is fixed 🥳 |
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
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.
The text was updated successfully, but these errors were encountered: