Z-Change Timelapse only on real z changes #1148
Conversation
… function in z-change mode so not on every z change pictures are captured but only on a real layer change
|
Thanks for this! Currently on vacation, will review and merge after new years, hope you understand :) |
|
No problem, thanks for the answer, thought anyone is interested ;) I am still thinking about the logic I inserted, because in addition to check the z change amount compared to the z hop setting I inserted a check where the hop has to be at least positive. This is right for my printer, but maybe there are printers out there where the z axis is counting to negative values? Also maybe a warning or notice to the setting could be inserted in the page stating that this will only work when the retraction z hop is different from the layer height... We can discuss when you're back. [Schöne Feiertage und einen guten Rutsch!] |
|
i was after this feature as well. yesterday i tried to activate timelapse with Z change and it end up a huge render. I`m waiting for this fix. |
|
@Alex9779 Consider me blushing heavily right now in embarrassment. I managed to completely forget that PR, although I even had made myself a TODO for after my vacation to process all PRs and issues, but this one somehow slipped through when I tackled that TODO, sorry :( I added two review comments, could you take a look if you have the time? If you don't, please tell me, I'll then take care of it myself. Also don't worry about the conflicts, those are my own fault for taking so long to really take a look at this PR, again sorry for that. I think it would probably also make sense to add a tooltip or some helper text to the configuration dialog to explain to people in short how the setting works (e.g. that it's important that the z-hop differs from the layer height in order for the detection to work). For the "positive difference" check: Hm... I can't remember there being printers that actually have the Z coordinate inverted. I don't know how the rest would OctoPrint would actually behave in such a case. Just to be on the safe side for now, it might make sense to only trigger the positive check if a z-hop value is actually defined, and otherwise just behave as previously? |
|
No problem... |
|
Oh dear, get well soon then! |
Alex9779
force-pushed
the
zChangeTimelapseWithRetractionZHop
branch
from
eb2896e
to
54ef930
Compare
|
Ok I fixed the indentation, made a comment on you other comment... |
|
Ok, perfect! How do we proceed with regards to a short inline help text and the "positive difference" check? |
|
If you are ok with a little waiting time then I will take care of it... About a week or two... Still eye problems. Have to build a BigBox too now ;)... |
|
No problem with waiting, just didn't want to leave things in an unclear who-waits-for-who state ;) |
foosel
added
the
needs some work
|
Ok did the requested changes. If the setting is "0" a snapshot is captured as before on every z-change. Will you do translation or should I? |
foosel
added
needs review
|
Finally came around to give this a final look over and merge it on 'devel`. Sorry again for the delay. I'll have to update the german translation for the I might still backport it to |
|
@foosel after some printing and time lapses I found that there is a small bug I think. |
|
Yes, please |
|
Trying this feature in 1.3.0rc1, but it does not appear to work. My layer height is 0.2mm My Z-hop is 0.42mm. Here is a video: https://www.youtube.com/watch?v=wGiRUrG8S-A Also - not sure if this is related, but while the setting for retraction Z-hop shows correctly throughout the print, the value does not appear to be saved. If I return to the Timelapse tab after the print is complete, it reverts to show 0. Attached is the OctoPrint log. Is there anything else I can provide to assist in troubleshooting? |
|
The video of the build process is definitely smoother. Unfortunately I am On Sat, Nov 5, 2016, 12:22 PM JohnOCFII notifications@github.com wrote:
|
Solves issue reported in #1148 for 1.3.0rc1
That was related and actually the cause. I refactored parts of the timelapse API to expect data as JSON and have the client also sent the data as JSON, but apparently before this PR was merged, so that didn't get the refactoring treatment and the setting simply got lost. That's fixed now and will be part of 1.3.0rc2 |
|
Confirming that on 1.3.0rc2 the timelapse correctly avoided taking images with Z-hop. :) |
| except ValueError: | ||
| return make_response("Invalid value for retraction Z-Hop: %r" % request.values["retractionZHop"]) | ||
| else: | ||
| if retractionZHop > 0: |
There was a problem hiding this comment.
This doesn't allow retractionZHop to be 0, but that is the default lower down. The effect is that if you switch to "Timed" and hit "Save Config" and then switch back to "On Z Change" it won't let you "Save Config" any more unless you set the retraction Z-hop to something non-zero. Is there a problem letting it be zero? If so, should we fix that problem or set the default to a small non-zero number (0.01mm)?
There was a problem hiding this comment.
IMHO there's no problem letting it be 0 and that should simply have been a >= instead of a >. Fixed accordingly on maintenance.
There was a problem hiding this comment.
If I follow correctly, in the meantime for those of us on master, if simply switch to "On Z-Change", set a retraction z-hop to something other than zero, save settings, change it back to zero, and save again it should work fine.
There was a problem hiding this comment.
Except that last step will hit the error again. If you just set the z-hop to something smaller than the lowest layer height you'll ever print, you'll be fine. 0.001 perhaps.
Hi there,
I am using OctoPrint for a while and its really cool. I improved my environment a few days ago to make it more easy to use for me in my workflow and I came accross the same issue I had when I first set it up for my printer: I wanted to do timelapse videos on z change but I have a retraction z-hop for printing, at least for some or most prints.
So I realized that the timelapse also captures images when the retraction occurs and this could be multiple times per layer in complex print.
The result is a long lasting time lapse where you only see the print head moving around.
So I added an addtional setting to the z-change timelapse option to be able to define the z-hop of the retraction and changed the capture event accroding to use that value and only capture images when the z move is positive AND not the same as the retraction z-hop.
So with this change it captures only images when a real layer z change happens.
Though there is one prerequesite: the retraction z hop has to be different to the layer height otherwise the calculation does not work. But unfortunately with my limited python knowledge I don't see any easy alternative to do the same with the values I have available when captuing images without changing the whole process of capturing.
I rounded the z value to 3 digits so a minimal difference should work too, like layer heigth 0.1 and retraction z hop 0.11.
I tested so far with a layer height of 0.1 and retraction z hop of 0.3. Works fine.
I uploaded two videos (created with current master without retraction z-hop recognition and created with my altered version with retraction z-hop recognition).
These were very simple parts with only one retraction per layer between the two cylinders but the second video is about half the lenght of the first one and IMHO a better timelapse.
If you have a lot of retractions on a layer then the timelapse is really bad.
One thing: I had to alter the less file and then recomplied it to the css but somehow I do not get the same result, maybe I am using not the right options? I just called
lessc --clean-css ..., mabye thats not right?Kind regards,
Alexander