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

Cura 2.5, TweakAtZ 5.1: layers count does not match Cura layers view mode #1855

Closed
anton-veretenenko opened this issue May 21, 2017 · 7 comments
Labels
Status: Deferred We don't have time to work on this for now but intend to in the future. Status: Stale ⌛ This issue is over a year old. It might be obsolete or just needs a fresh set of eyes Type: Bug The code does not produce the intended behavior.

Comments

@anton-veretenenko
Copy link

In "View Mode: Layers" Cura counting layers starting from 1. Gcode files are generated with layers counting from 0. And TweakAtZ also count layers starting from 0. So it is always a miss if you enter a layer number from Cura layers view mode into TweakAtZ instance.

@Ghostkeeper
Copy link
Collaborator

Perhaps subtracting 1 from the layer indicated in TweakAtZ would suffice.

@anton-veretenenko
Copy link
Author

yes, but TweakAtZ accepting layer 0, at least for now.

@Ghostkeeper
Copy link
Collaborator

I see. It actually looks for the ;LAYER: comments in the code and bases it on that. In fact it accepts layer numbers down to -100. These are the raft layers, which have negative layer numbers.

@Ghostkeeper Ghostkeeper added the Type: Bug The code does not produce the intended behavior. label May 22, 2017
@Ghostkeeper
Copy link
Collaborator

The pull request over at Ultimaker/Uranium#258 mentions that it would fix this bug, but it doesn't. It has nothing to do with this issue.

@Ghostkeeper
Copy link
Collaborator

The ticket for this bug was just removed from our planning by our project manager for being more than 3 months old.

@ianpaschal ianpaschal added the Status: Won't Fix/Do Not an issue, or an issue that we cannot fix or can live with. label Feb 21, 2018
@Ghostkeeper Ghostkeeper added Category: Cura Status: Deferred We don't have time to work on this for now but intend to in the future. and removed Status: Won't Fix/Do Not an issue, or an issue that we cannot fix or can live with. labels Mar 13, 2018
@Ghostkeeper Ghostkeeper reopened this Mar 13, 2018
@github-actions
Copy link
Contributor

Hi 👋,
We are cleaning our list of issues to improve our focus.
This bug seems to be older than a year, which is at least three major Cura releases ago.
It also received the label Deferred indicating that we did not have time to work on it back then and haven't found time to work on it since.

If this is still a problem for you in the current version of Cura, can you please leave a comment?
We will have a fresh set of eyes to look at it.

If it is not a problem anymore, you don't have to do anything, and this issue will be automatically closed in 14 days.

@github-actions github-actions bot added the Status: Stale ⌛ This issue is over a year old. It might be obsolete or just needs a fresh set of eyes label Jun 10, 2023
@github-actions
Copy link
Contributor

This issue was closed because it has been inactive for 14 days since being marked as stale.
If you encounter this issue and still experience this to be a problem, you are welcome to make a fresh new issue with an updated description and screenshots.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Deferred We don't have time to work on this for now but intend to in the future. Status: Stale ⌛ This issue is over a year old. It might be obsolete or just needs a fresh set of eyes Type: Bug The code does not produce the intended behavior.
Projects
None yet
Development

No branches or pull requests

4 participants