Octoprint: Timelapse on Z change failing at z-hop

[wcatherall]

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]

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]

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]

I've uploaded 2 test gcode files.

z-hop set to 0 mm:
https://gist.github.com/wcatherall/2ced26a853999656966ca3727053ce04

z-hop set to 0.5 mm:
https://gist.github.com/wcatherall/5dc01c343749d15949c023d2ec77d782

[foosel]

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!

[DerMaulwurf]

Dear Gina,

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

Best regards,
Markus

[foosel]

1.3.2 was just released.

[wcatherall]

Awesome. It works great, thanks!