The first few seconds skipped

[ogland]

If this is a feature request describe it here

FEATURE_REQUEST_DESCRIPTION_GOES_HERE

Version of Octolapse

Octolapse Version: Octolapse Vv0.2.6

Version of OctoPrint

OctoPrint Version: OctoPrint 1.3.7rc3

When you ran into the problem, did you have diagnostic logging enabled?

Diagnostic Logging was Enabled: no

What were you doing when the problem occurred

1. Printed
2. Saved video
3. Played video

What should have happened?

The entire video should have played

What happened instead?

The first few seconds skipped

Operating System running OctoPrint and Octolapse

OS Name: OS_NAME_GOES_HERE Os Version: OS_VERSION_GOES_HERE

Printer model & used firmware incl. version

Printer Model: Prusa i3 Mk2s Printer Firmware Version: PRINTER_FIRMWARE_VERSION_GOES_HERE

Browser and version of browser, operating system running browser

Browser: Chrome Browser OS: Android

Link to the gcode file you were printing when the problem occurred

Link to Gcode File: http://www.ogland.org/downloads/files/local/Makers_Muse_Torture_Egg.gcode

Link to settings.json

Link to settings.json with all passwords removed: SETTINGS_JSON_LINK_GOES_HERE

Link to plugin_octolapse.log

Link to plugin_octolapse.log: LINK_GOES_HERE

Link to octoprint.log

Link to octoprint.log: LINK_GOES_HERE

Link to contents of Javascript console in the browser

Link to javascript console output: LINK_GOES_HERE

Screenshots and/or videos of the problem:

Screenshot/Video Links: LINKs_GO_HERE

[FormerLurker]

Can you post the timelapse? My guess is that your printer primes pretty high 15mm maybe), and coincidentally you are missing the first 15mm of the timelapse, no? If that is the case, just go into your printer profile in octolapse and set the priming height, let's say to 0.5mm (at or below where your printer primes but above the first layer).

Let me know if that helps.

On Sun, Apr 1, 2018, 7:49 AM ogland notifications@github.com wrote:

If this is a feature request describe it here

FEATURE_REQUEST_DESCRIPTION_GOES_HERE Version of Octolapse

Octolapse Version: Octolapse Vv0.2.6 Version of OctoPrint

OctoPrint Version: OctoPrint 1.3.7rc3 When you ran into the problem, did you have diagnostic logging enabled?

Diagnostic Logging was Enabled: no What were you doing when the problem occurred

1. Printed
2. Saved video
3. Played video

What should have happened?

The entire video should have played What happened instead?

The first few seconds skipped Operating System running OctoPrint and Octolapse

OS Name: OS_NAME_GOES_HERE Os Version: OS_VERSION_GOES_HERE Printer model & used firmware incl. version

Printer Model: Prusa i3 Mk2s Printer Firmware Version: PRINTER_FIRMWARE_VERSION_GOES_HERE Browser and version of browser, operating system running browser

Browser: Chrome Browser OS: Android Link to the gcode file you were printing when the problem occurred

Link to Gcode File: http://www.ogland.org/downloads/files/local/Makers_Muse_Torture_Egg.gcode Link to settings.json

Link to settings.json with all passwords removed: SETTINGS_JSON_LINK_GOES_HERE Link to plugin_octolapse.log

Link to plugin_octolapse.log: LINK_GOES_HERE Link to octoprint.log

Link to octoprint.log: LINK_GOES_HERE Link to contents of Javascript console in the browser

Link to javascript console output: LINK_GOES_HERE Screenshots and/or videos of the problem:

Screenshot/Video Links: LINKs_GO_HERE

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/Octolapse/issues/115, or mute the thread https://github.com/notifications/unsubscribe-auth/Af0UuITmv8Q2O23i77hQhw1Fs4hBEH-Nks5tkMzRgaJpZM4TC0bo .

[ogland]

It primes at the first layer, as most mk2s'es do. That is at 0,2 mm. You can see it in the gcode pretty clearly.

Here is the timelapse. http://www.ogland.org/downloads/timelapse/benchycubefrogcorners_20180401121238.mp4

I also tried printing some stuff that was below 15 mm high and that did not render a timelapse at all.

[FormerLurker]

Yeah, sorry, just drug myself out of bed and wasn't thinking clearly. Taking a look at the code now.

[FormerLurker]

Here are two things you should do:

1. Can you try adding G80 to the 'Additional location detection commands' found within the printer profile? This will cause Octolapse to request a position after the G80 is completed.
2. Also, make sure you configure your print volume. I notice there is movement to Y=-3. You could adjust your Octoprint printer profile if it is not already done (must include the custom box starting at y=-3), OR you can override Octoprint's settings in the printer profile under Print Volume. Your current settings may be correct, btw, I just can't tell.

Additionally, some of the start GCode looks odd. For example, line 25: G92 X0 ; tell printer its really at X0 Not that it's a mistake, but why is it setting X to 0 before a home operation? What purpose does that serve? I would think you would want to home X first, then set X=0 after, like this G28 X G92 X0 ; still, why do we need this?

Line 30 - 32: Why is the gcode raising Z by 10 and lowering it by 50 here? Seems to me like this could drive the nozzle into the bed, depending on it's starting position. Octolapse threw some position errors here because of this, and Octoprint complains about an out-of-bounds object as well due to this I believe.

Also, I noticed you have linear advance enabled. In some cases (at least for Prusa Mk2), this can lead to lockups due to serial issues within the firmware, especially when running Octolapse (M400 can cause it, and octolapse sends lots of those). This is being worked on, and probably doesn't affect all firmware, but please be aware of this. If you get a lockup you can try two things:

1. Go into the terminal tab, expand the advanced section and force an Ok.
2. If that doesn't work, type: M114 into the terminal window and press enter. Sounds odd, I know, and it probably won't affect you, but I thought I'd mention it just in case.

I'm still running some tests, and I've made some changes to the G92 command, so hopefully Octolapse will be more tolerant of these situations in the future. I'll report back soon, but let me know if any of those steps above helped.

Thanks!

[ogland]

The size of the box in octoprint needs to be Y-3 because that is where the priming happens. It is adjusted in the octoprint printer profile since it wont print otherwise :)

Regarding the G92 X0 it should not be where it is. I blame a tired brain for this and I thank you for noticing! It's there because there is some clearances that needs to be adjusted. Just a poor solution really.

Line 30 - 32 is doing that operation as a response to the ending gcode, thereby first leveling the gantry by raising it beyond the top and then giving the home of x axis a bit of clearance since the frame demands it. I could do with a lower number. But the initial position is at the top in order for the inductive sensor to keep cool.

Gonna try adding the G80 and then print another abomination.

[FormerLurker]

Hey, FYI, it's hard to test this with the virtual printer, but I think my suggestions should work. I was able to get snapshots to start on Z=0.2 and continue thereafter. If the suggestions don't work for you, I could suggest some changes in your startup gcode that would probably make it work.

FYI, I did change the behavior of G92 a bit over the last 24 hours, so it is possible that my suggestions will work, but only with the code in the devel branch (I just pushed my changes). I don't recommend trying this branch until I've run a barrage of tests, changed lots of stuff that needs testing.

[ogland]

Where do I find this 'Additional location detection commands'? Is it in octoprint? Or in my slicer? I use Slic3rPE mainly.

[FormerLurker]

In the Octolapse settings, in the printer profiles tab. Check out the wiki here

[ogland]

Thanks! Giving the print a go now, will report back :)

[ogland]

As it turns out it does indeed fail with linear advance and since print quality and speed is something that I'm not willing to give up, octolapse won't work for me :(

[FormerLurker]

Sorry to hear that. If you're interested, there is a firmware update for mk2/mk2 w mmu, but it isn't official yet. Prusa will likely fix this themselves at some point.

[FormerLurker]

Hey, I found the pull request for the firmware fix for the LA issue: https://github.com/prusa3d/Prusa-Firmware/pull/504

A word of warning: The linear advance failures you are seeing with Octolapse could happen with any serial print with linear advance enabled(even a 36 hour one as I learned), especially if it sends lots and lots of small gcodes (high quality slicing), so it's probably best to print from the SD if you don't want to ever run into any freezes with linear advance, or to update to sebastian's firmware build above.

Good luck!

[FormerLurker]

I'm closing the issue since I cannot resolve the Prusa LA firmware bug on my own, and because the original issue has been solved. However, let me know if there's anything else I can do!