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

Timelapse on Z change failing at z-hop #1777

Closed
wcatherall opened this issue Feb 17, 2017 · 7 comments

Comments

Projects
None yet
3 participants
@wcatherall
Copy link

commented Feb 17, 2017

What were you doing?

I'm attempting to do timelapse on z change. Using 30 fps, 2 sec post roll, 0.5 mm z-hop.

What did you expect to happen?

I expected the timelapse function to take photos on every layer change. Things work fine when using the
timed mode.

What happened instead?

Timelapse took photos every layer until I had layers with z-hop. Using Slic3r, I have z-hop set to 0.5 mm and it starts using z-hop above 1 mm. With layer height of 0.1 mm, I get nice snapshots every 0.1 mm until height 1.1 mm when z hop kicks in. Then timelapse stops taking snapshots.

Branch & Commit or Version of OctoPrint

Version 1.3.1 (master branch)

Printer model & used firmware incl. version

Original Prusa i3 MK2, firmware 3.0.9

Browser and Version of Browser, Operating System running Browser

Chrome

Link to octoprint.log

https://gist.github.com/wcatherall/252a82fe3ed999ef9fcf2dc1bf8d24b8

Link to contents of terminal tab or serial.log

Link to contents of Javascript console in the browser

Screenshot(s) showing the problem:

I have read the FAQ.

@DerMaulwurf

This comment has been minimized.

Copy link

commented Feb 21, 2017

let's take a look at a sample g-codes (slic3r). Layer height in this example is 0.35 mm.
For the first tree layers, everything works as it should. One initial image and tree addition images are created.
The codes are:

G1 Z0.200
G1 Z0.550
G1 Z0.900
;Layer 4 is at 1.25 mm height. From now on z-hopping is used (0.5mm)
G1 Z1.250
G1 Z1.750
;a lot more of hopping ...
G1 Z1.250
G1 Z1.750
;the head is now at 1,75 mm height and moves to the initial x-y-position for the next layer
G1 Xxxxx Yyyyy
and now it moves to the Z-height of the new layer no. 5
G1 Z1.600
this is the moment to take the picture, but this never happens.

The issue results from the fact, that the Z-height of the new layer is LOWER then the Z-height while in z-hopping. The head is at height 1.75 while in transit and then it goes down to 1.6 to start printing.

Have a look an timelapse.py, class ZTimelapse(Timelapse):

# check if height difference equals z-hop or is negative, if so don't take a picture
diff = round(payload["new"] - payload["old"], 3)
zhop = round(self._retraction_zhop, 3)
if diff == zhop or diff <= 0:
return

Best regards,
Markus

@foosel

This comment has been minimized.

Copy link
Owner

commented Feb 22, 2017

Thanks Markus. I'll have to dig into the code and the PR that introduced it again and try to remember why stuff was done the way it was. I fear it might have something to do with implementation differences across various slicers when it comes to z-hop.

If either of you two could provide a full test GCODE file that would be helpful.

@wcatherall

This comment has been minimized.

Copy link
Author

commented Feb 22, 2017

foosel added a commit that referenced this issue Feb 23, 2017

Timelapse: ignore both z-hop flanks but allow z-hop to next layer
Former implementation tested for z-hop rising flank and anything that
is falling. That however causes issues with z-hop directly followed
by layer change (diff is not z-hop size but negative, image hence not
captured).

Instead of testing for positive flank == z-hop and any negative flank,
we now test for absolute value == z-hop.

Solves #1777
@foosel

This comment has been minimized.

Copy link
Owner

commented Feb 23, 2017

Fixed with the above commit. To quote the explanation:

Former implementation tested for z-hop rising flank and anything that is falling. That however causes issues with z-hop directly followed by layer change (diff is not z-hop size but negative, image hence not captured).

Instead of testing for positive flank == z-hop and any negative flank, we now test for absolute value == z-hop.

So - solved on maintenance, soon to also be merged to devel and this will be part of the 1.3.2 release. Thanks for reporting!

@foosel foosel added this to the 1.3.2 milestone Feb 23, 2017

@DerMaulwurf

This comment has been minimized.

Copy link

commented Feb 23, 2017

Dear Gina,

that was a swift response!
Thanks for your great work.

Best regards,
Markus

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 16, 2017

1.3.2 was just released.

@foosel foosel closed this Mar 16, 2017

@wcatherall

This comment has been minimized.

Copy link
Author

commented Mar 19, 2017

Awesome. It works great, thanks!

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.