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

Z-Change Timelapse only on real z changes #1148

Merged
merged 4 commits into from Mar 18, 2016

Conversation

Projects
None yet
7 participants
@Alex9779
Copy link
Contributor

commented Dec 16, 2015

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

added "Retraction Z-Hop" setting to timelapse and altered the capture…
… function in z-change mode so not on every z change pictures are captured but only on a real layer change
@foosel

This comment has been minimized.

Copy link
Owner

commented Dec 27, 2015

Thanks for this! Currently on vacation, will review and merge after new years, hope you understand :)

@Alex9779

This comment has been minimized.

Copy link
Contributor Author

commented Dec 28, 2015

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!]

@MertMG

This comment has been minimized.

Copy link

commented Mar 2, 2016

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.

@foosel

This comment has been minimized.

Copy link

commented on src/octoprint/timelapse.py in 6962fad Mar 7, 2016

Looks like there's a small indentation error here (leading space)

@foosel

This comment has been minimized.

Copy link

commented on src/octoprint/server/api/timelapse.py in 6962fad Mar 7, 2016

Why not

config["retractionZHop"] = timelapse.retraction_zhop

like the others? Or moving the others over to

config.update(dict(type="zchange",
                   postRoll=timelapse.post_roll,
                   fps=timelapse.fps,
                   retractionZHop=timelapse.retraction_zhop))

Might be missing something here...

This comment has been minimized.

Copy link
Owner Author

replied Mar 7, 2016

Ok I figured out why I did that. Look at the lines below. On an interval time-lapse there is the interval as the setting only for this type. So when I introduced the new setting specific for the z change time-lapse I copied the style from below.

This comment has been minimized.

Copy link

replied Mar 7, 2016

Ok, ignore that then, entirely my-former-self's fault ;)

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 7, 2016

@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?

@Alex9779

This comment has been minimized.

Copy link
Contributor Author

commented Mar 7, 2016

No problem...
I will have a look, currently I have a huge problem with my eyes, could take a week until I will be able to write more than comment...

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 7, 2016

Oh dear, get well soon then!

@Alex9779 Alex9779 force-pushed the Alex9779:zChangeTimelapseWithRetractionZHop branch from eb2896e to 54ef930 Mar 7, 2016

@Alex9779

This comment has been minimized.

Copy link
Contributor Author

commented Mar 7, 2016

Ok I fixed the indentation, made a comment on you other comment...

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 8, 2016

Ok, perfect!

How do we proceed with regards to a short inline help text and the "positive difference" check?

@Alex9779

This comment has been minimized.

Copy link
Contributor Author

commented Mar 9, 2016

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 ;)...

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 9, 2016

No problem with waiting, just didn't want to leave things in an unclear who-waits-for-who state ;)

@Alex9779

This comment has been minimized.

Copy link
Contributor Author

commented Mar 13, 2016

Ok did the requested changes. If the setting is "0" a snapshot is captured as before on every z-change.
I also added a text to the setting with the remarks.
Hope this is ok so. Just change it if you don't like it.

Will you do translation or should I?

@foosel foosel self-assigned this Mar 13, 2016

@foosel foosel merged commit 2a28714 into foosel:devel Mar 18, 2016

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 18, 2016

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 devel branch sometime anyhow, one string more or less won't matter there ;)

I might still backport it to maintenance, but for now I'll leave it on devel since I want to get this ready for release anyhow sooner rather than later (it's been in the works for far too long now anyhow since I constantly have to switch back and forth between devel and maintenance work...).

@Alex9779

This comment has been minimized.

Copy link
Contributor Author

commented Mar 25, 2016

@foosel after some printing and time lapses I found that there is a small bug I think.
If I do not select a z hop distance and leave it at 0 then the settings seem not to be saved.
You can see this if you have selected another type of time lapse of non. When you then change to Z time lapse and leave the Z hop value at 0 and hit save nothing happens.
I am going to have a look at that, if I can correct it shall I make a PR against the devel branch?

@Alex9779

This comment has been minimized.

Copy link
Owner Author

commented on src/octoprint/server/api/timelapse.py in 6962fad Mar 25, 2016

@foosel here is the problem, comparison must be ">= 0", 0 is a valid value...

This comment has been minimized.

Copy link

replied Mar 29, 2016

Hm, but that shouldn't cause issues here, since it's set to 0 initially (line 121) and only changed here if it differs from 0?

This comment has been minimized.

Copy link
Owner Author

replied Mar 30, 2016

Initially yes no problem. But if you have a time-lapse config on and want to disable the z hop setting you can save...

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 29, 2016

Yes, please

@JohnOCFII

This comment has been minimized.

Copy link

commented Nov 5, 2016

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
Here is the gcode I printed:
Eiffel_Tower_mini_150p_MK2.gcode.zip

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?
octoprint.log.2016-11-01.html.zip

@idh

This comment has been minimized.

Copy link

commented Nov 5, 2016

The video of the build process is definitely smoother. Unfortunately I am
no longer at the compqny working on the project so I won't be able to try
it myself right now. My hope is to pick it back up in a few months.

On Sat, Nov 5, 2016, 12:22 PM JohnOCFII notifications@github.com wrote:

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
Here is the gcode I printed:
Eiffel_Tower_mini_150p_MK2.gcode.zip
https://github.com/foosel/OctoPrint/files/573332/Eiffel_Tower_mini_150p_MK2.gcode.zip

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?
octoprint.log.2016-11-01.html.zip
https://github.com/foosel/OctoPrint/files/573338/octoprint.log.2016-11-01.html.zip


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1148 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABBoRHbCrMzutDCDcrpVyw3-yHBZVsW9ks5q7K04gaJpZM4G2bhF
.

foosel added a commit that referenced this pull request Nov 9, 2016

Fixed retractionZHop setting for Z timelapses
Solves issue reported in #1148 for 1.3.0rc1
@foosel

This comment has been minimized.

Copy link
Owner

commented Nov 9, 2016

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

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

@JohnOCFII

This comment has been minimized.

Copy link

commented Nov 26, 2016

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:

This comment has been minimized.

Copy link
@markwal

markwal Dec 31, 2016

Collaborator

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)?

This comment has been minimized.

Copy link
@foosel

foosel Jan 9, 2017

Owner

IMHO there's no problem letting it be 0 and that should simply have been a >= instead of a >. Fixed accordingly on maintenance.

This comment has been minimized.

Copy link
@synman

synman Jan 18, 2017

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.

This comment has been minimized.

Copy link
@markwal

markwal Jan 19, 2017

Collaborator

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.

foosel added a commit that referenced this pull request Jan 9, 2017

DeviousFusion pushed a commit to UTA-FabLab/OctoPuppet that referenced this pull request Sep 12, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.