Printing randomly freezes when Octolapse is enabled

[rvarella75]

If this is a feature request describe it here

_REPLACE_THISFEATURE_REQUEST_DESCRIPTION_GOES_HERE

Version of Octolapse

Octolapse Version: v0.4.0

Version of OctoPrint

OctoPrint Version: 1.4.0

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

Diagnostic Logging was Enabled: YES

What were you doing when the problem occurred

1. When I have Octolapse enabled printer freezes randomly. Sometimes it will be early in the printing, sometimes closer to end. If I disable Octolapse printing will complete successfully.
2. Did not make any major changes except to enable DLSR but I get the same regardless of using the PI webcam or the DSLR.
3. Tried different PIs with the same behavior.

What should have happened?

Printing should have completed

What happened instead?

Printing stoped mid print

Operating System running OctoPrint and Octolapse

OS Name: OctoPI Os Version: 0.17.0

Printer model & used firmware incl. version

Printer Model: Monoprice MP10 3D Printer Firmware Version: 72 PROTOCOL_VERSION:1.0 MACHINE_TYPE:Malyan 3D Printer

Browser and version of browser, operating system running browser

Browser: Chrome Browser OS: OSX

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

Link to Gcode File: https://www.dropbox.com/s/gpjwayfrlrdh46r/CFFFP_batmanbust.gcode?dl=0

Link to settings.json

Link to settings.json with all passwords removed: https://www.dropbox.com/s/vttguci14m9u0pd/settings%20%282%29.json?dl=0

Link to plugin_octolapse.log

Link to plugin_octolapse.log: https://www.dropbox.com/s/35vp175lc2916w2/plugin_octolapse%20%2817%29.log?dl=0

Link to octoprint.log

Link to octoprint.log: https://www.dropbox.com/s/zfmuibafxlizo34/octoprint%20%2814%29.log?dl=0

Link to Serial.log: https://www.dropbox.com/s/55uyru7e0uhhwq1/serial%20%289%29.log?dl=0

Link to contents of Javascript console in the browser

Link to javascript console output: _REPLACE_THISLINK_GOES_HERE

Screenshots and/or videos of the problem:

Screenshot/Video Links: _REPLACE_THISLINKs_GO_HERE

Please consider becoming a patron

If you like this project, please support my work by becoming a patron, and consider adding a 'star' to the repository. It takes a lot of time and effort to maintain the project and respond to issues. The cost of test prints, software, cameras, printer parts, etc. can quickly add up, so every bit helps.

You can find various videos and tutorials by subscribing to my Youtube channel. You can also follow me on Twitter.

[FormerLurker]

Does it freeze while taking a snapshot ot just before? You should be able to look at the snapshot plan info panel if you are using the smart triggers and see where in the process it is.

[rvarella75]

No it freezes while printing most of the times.

[rvarella75]

Just run another test. Seems it is just before.

[FormerLurker]

Check the camera timeout in your dslr profile. Set it to 5000MS. That way if it takes more that 5 seconds to acquire an image it will bail. IMHO that is better than stalling out a print.

I will come up with some script debug steps, but I suspect some delay in gphoto2 or your dslr. They can be pretty finicky sometimes.

[rvarella75]

I made the change but it's still happening. The nozzle stops on the last printing position so it's not so it's before it moves for the camera to take the snapshot. The problem also happens with the PI camera so it does not seem to be the camera causing the issue.

[rvarella75]

Video is bad but here is it happening. Hopefully it helps to explain better.

https://www.dropbox.com/s/ez0u1p7bxwahrye/printfail.mp4?dl=0

[FormerLurker]

So, at the end of this video, did you cancel the print, or was it hanging there? If it was hanging, can you keep filming and show when it starts up again (It could be a few minutes potentially)? I recommend running in test mode so you don't waste any plastic.

I've been looking at your log, but so far I haven't found anything unusual, though it is a lot to look through since I have to manually examine every snapshot since I don't know which one failed. Ideally the log would end after a stall so I could look at the very bottom and find the report that includes the stalling.

[rvarella75]

It just hangs there and after a few seconds it will fail and say communication timeout.

this is the line in Octolapse log where it fails 2020-06-14 14:43:01,474 - octolapse.timelapse - DEBUG - Snapshot gcode SNAPSHOT - sent: G0 X3.000 Y297.000 F7200.000

This is the line on Octoprint log

2020-06-14 14:43:14,149 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.

On serial.log

2020-06-14 14:43:01,474 - Send: N9272 G0 X3.000 Y297.000 F7200.000*100

Thank you for looking into this.

[FormerLurker]

FYI, If the lockup you logged occurred at the very end of the print, it's looking like serial communication stopped working:

2020-06-14 14:43:14,149 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2020-06-14 14:43:24,168 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2020-06-14 14:43:34,192 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2020-06-14 14:43:44,216 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2020-06-14 14:43:54,242 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2020-06-14 14:44:04,262 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2020-06-14 14:44:14,281 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2020-06-14 14:44:24,307 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2020-06-14 14:44:34,328 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2020-06-14 14:44:44,353 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2020-06-14 14:44:54,370 - octoprint.util.comm - INFO - No response from printer after 11 consecutive communication timeouts, considering it dead.
2020-06-14 14:44:54,407 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)"

I have verified this in the Octolapse log:

2020-06-14 14:43:01,474 - octolapse.timelapse - DEBUG - Snapshot gcode SNAPSHOT - sent: G0 X3.000 Y297.000 F7200.000
2020-06-14 14:43:03,950 - octolapse.timelapse - VERBOSE - Queuing: M105
2020-06-14 14:43:03,951 - octolapse.gcode_position - VERBOSE - Updating current position from gcode.
2020-06-14 14:43:08,954 - octolapse.timelapse - VERBOSE - Queuing: M105
2020-06-14 14:43:08,956 - octolapse.gcode_position - VERBOSE - Updating current position from gcode.
2020-06-14 14:43:13,963 - octolapse.timelapse - VERBOSE - Queuing: M105
2020-06-14 14:43:13,964 - octolapse.gcode_position - VERBOSE - Updating current position from gcode.
2020-06-14 14:43:14,147 - octolapse.timelapse - VERBOSE - Received: 
2020-06-14 14:43:14,155 - octolapse.timelapse - VERBOSE - Queuing: M105

Notice that no responses appear after Octolapse sent the G0 X3.000 Y297.000 F7200.000 command. Commands were sent to the printer, but there was no response, and the printer disconnected. Your printer isn't responding to anything at this point, including temperature requests (M105).

Also, I see you are using Octolapse (0.4.0rc3). Please upgrade to V0.4.0 via the software update plugin. There were a few bugs fixed between rc3 and v0.4.0 (handling disconnects and cancelled prints is actually one of those). I'm still not at all sure why the disconnect occurred.

I see you just replied with the same findings. I started from the top of the log and worked my way down, so it took me a while to see the same things you did.

[rvarella75]

I'm using 4.0 already. The first time I tried Octolapse it was v3.4 (the same thing would happen) and I have been working my way with your RCs. When I saw 4.0 I immediately upgraded it hoping the issue would be finally gone but when I still would get the same I decided to finally bother you :)

[FormerLurker]

That's really strange. Here's what I see in your octoprint.log file:

| Octolapse (0.4.0rc3) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_octolapse

Here's what's in mine:

| Octolapse (0.4.0) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_octolapse

It's DEFINITELY possible that there was some kind of issue migrating between the dev and rc versions along the way. I fixed install and update problems right down to release day for V0.4.0. It might be a good idea to uninstall and clean Octolapse, then try a reinstall and see if the version changes in the octoprint.log file. I know this will be somewhat of a pain, but it would eliminate any problems springing from bugs in the upgrade process (especially those caused by errors in rc and rc/devel builds).

[rvarella75]

Yeah I had thought about that after I replied to you and have already done it. Running a new test with clean logs. will let you know how it goes.

[FormerLurker]

Fantastic! Thank you for being so responsive and thorough. It REALLY helps and I appreciate it a ton.

[rvarella75]

Same thing after removing everything and installing 4.0. Here we go: plugin_octolapse (6).log

For some reason it only created the octolapse log so this is the only one I have for this test.

No man I'm the one to thank you! I'm an IT Operations Manager. If half of my support teams would be as responsive as you are my life would be so much better!! Very impressive!

Thank you!

[rvarella75]

New test with serial.log and octoprint.log working serial (3).log octoprint (1).log plugin_octolapse (7).log

[FormerLurker]

Wow, that time it disconnected and it was NOT attempting to take a snapshot:

2020-06-15 11:54:31,432 - octolapse.timelapse - VERBOSE - Queuing: G1 X132.315 Y150.005 E630.65241
2020-06-15 11:54:31,432 - octolapse.timelapse - VERBOSE - Sending: G1 Y149.804 X132.643
2020-06-15 11:54:31,432 - octolapse.gcode_parser - VERBOSE - Parsing gcode.
2020-06-15 11:54:31,434 - octolapse.timelapse - DEBUG - Sent: G1 Y149.804 X132.643
2020-06-15 11:54:42,194 - octolapse.timelapse - VERBOSE - Received: 
2020-06-15 11:54:42,206 - octolapse.timelapse - VERBOSE - Queuing: M105
2020-06-15 11:54:42,210 - octolapse.gcode_parser - VERBOSE - Parsing gcode.
2020-06-15 11:54:42,216 - octolapse.timelapse - VERBOSE - Sending: G1 Y150.005 X132.315
2020-06-15 11:54:42,219 - octolapse.timelapse - DEBUG - Sent: G1 Y150.005 X132.315
2020-06-15 11:54:52,224 - octolapse.timelapse - VERBOSE - Received: 
2020-06-15 11:54:52,233 - octolapse.timelapse - VERBOSE - Queuing: M105
2020-06-15 11:54:52,236 - octolapse.gcode_parser - VERBOSE - Parsing gcode.
2020-06-15 11:55:02,244 - octolapse.timelapse - VERBOSE - Received: 
2020-06-15 11:55:02,253 - octolapse.timelapse - VERBOSE - Queuing: M105

It continues like this until the printer disconnects. This is most confusing. You've already said this does not happen without Octolapse enabled, but it appears to be doing what it should (at least according to the logs). What I need to figure out is why the printer stops responding when Octolapse is enabled.

So, one thing I thought of is that perhaps there is some kind of conflict with another plugin you have installed. Would you be able to disable the non-bundled plugins you have installed and see if the same thing happens? It may turn out to be nothing, but if Octolapse starts working as expected this may just explain everything. Unfortunately, if it keeps disconnecting like you've shown in the log we'll be back to square one.

I did notice one unusual thing in the serial log. A timeout is detected, THEN another command is send, but no response is received in either case. Here is the log for that bit:

2020-06-15 11:54:31,433 - Send: N8486 G1 Y149.804 X132.643*26
2020-06-15 11:54:42,201 - Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
2020-06-15 11:54:42,218 - Send: N8487 G1 Y150.005 X132.315*28
2020-06-15 11:54:52,228 - Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.

I'll look into this.

[rvarella75]

Tried disabling all plugins as you suggested and same result:

This is where it stopped this time: serial (3).log plugin_octolapse (5).log octoprint.log

[rvarella75]

Are the M105 sent by Octolapse? If that is the case maybe when the timeout happens with Octolapse disable it just keeps going but when it's enabled Octoprint waits for the M105 response and it fails?

Here is what I mean: 2020-06-15 10:54:42,780 - octolapse.timelapse - VERBOSE - Sending: G1 Y167.677 X169.941 F3000.0 2020-06-15 10:54:42,783 - octolapse.timelapse - DEBUG - Sent: G1 Y167.677 X169.941 F3000.0 2020-06-15 10:54:52,791 - octolapse.timelapse - VERBOSE - Received: 2020-06-15 10:54:52,802 - octolapse.timelapse - VERBOSE - Queuing: M105 2020-06-15 10:54:52,804 - octolapse.gcode_parser - VERBOSE - Parsing gcode. 2020-06-15 10:55:02,817 - octolapse.timelapse - VERBOSE - Received: 2020-06-15 10:55:02,824 - octolapse.timelapse - VERBOSE - Queuing: M105 2020-06-15 10:55:02,827 - octolapse.gcode_parser - VERBOSE - Parsing gcode. 2020-06-15 10:55:12,846 - octolapse.timelapse - VERBOSE - Received: 2020-06-15 10:55:12,852 - octolapse.timelapse - VERBOSE - Queuing: M105 2020-06-15 10:55:12,858 - octolapse.gcode_parser - VERBOSE - Parsing gcode. 2020-06-15 10:55:22,873 - octolapse.timelapse - VERBOSE - Received: 2020-06-15 10:55:22,880 - octolapse.timelapse - VERBOSE - Queuing: M105 2020-06-15 10:55:22,882 - octolapse.gcode_parser - VERBOSE - Parsing gcode. 2020-06-15 10:55:32,895 - octolapse.timelapse - VERBOSE - Received: 2020-06-15 10:55:32,903 - octolapse.timelapse - VERBOSE - Queuing: M105 2020-06-15 10:55:32,904 - octolapse.gcode_parser - VERBOSE - Parsing gcode. 2020-06-15 10:55:42,918 - octolapse.timelapse - VERBOSE - Received: 2020-06-15 10:55:42,926 - octolapse.timelapse - VERBOSE - Queuing: M105 2020-06-15 10:55:42,930 - octolapse.gcode_parser - VERBOSE - Parsing gcode. 2020-06-15 10:55:52,944 - octolapse.timelapse - VERBOSE - Received: 2020-06-15 10:55:52,955 - octolapse.timelapse - VERBOSE - Queuing: M105 2020-06-15 10:55:52,956 - octolapse.gcode_parser - VERBOSE - Parsing gcode. 2020-06-15 10:56:02,961 - octolapse.timelapse - VERBOSE - Received: 2020-06-15 10:56:02,968 - octolapse.timelapse - VERBOSE - Queuing: M105 2020-06-15 10:56:02,970 - octolapse.gcode_parser - VERBOSE - Parsing gcode. 2020-06-15 10:56:12,977 - octolapse.timelapse - VERBOSE - Received: 2020-06-15 10:56:12,981 - octolapse.timelapse - VERBOSE - Queuing: M105 2020-06-15 10:56:12,986 - octolapse.gcode_parser - VERBOSE - Parsing gcode. 2020-06-15 10:56:23,001 - octolapse.timelapse - VERBOSE - Received: 2020-06-15 10:56:23,063 - octolapse.timelapse - INFO - Snapshot jobs queue has completed, starting to render.

[FormerLurker]

No, those are sent by Octoprint in order to monitor the temperatures. So I'll annotate your example logs:

2020-06-15 10:54:42,780 - octolapse.timelapse - VERBOSE - Sending: G1 Y167.677 X169.941 F3000.0

Here Octolapse is reporting that OctoPrint is about to send the G1 above, but it hasn't been sent to the printer.

2020-06-15 10:54:42,783 - octolapse.timelapse - DEBUG - Sent: G1 Y167.677 X169.941 F3000.0

Here Octolapse is reporting that OctoPrint has sent the gcode to your printer.

2020-06-15 10:54:52,791 - octolapse.timelapse - VERBOSE - Received:

Here is where things go wrong. OctoPrint hasn't received any response from your printer. It responded, but it didn't send any text. This is confirmed in the OctoPrint serial log.

2020-06-15 10:54:52,802 - octolapse.timelapse - VERBOSE - Queuing: M105

Every so often OctoPrint sends M105 to get temp readings to update the temperature tab. It doesn't look like these commands were actually sent, and are just queued up while OctoPrint tries to get a response out of your printer. At this point no gcodes will be sent until OctoPrint gets some kind of response (I'm pretty sure that's correct).

The $10,000 question is: Why is communication stopping only when Octolapse is enabled? In the example above the printer quit responding to commands sent by OctoPrint, not Octolapse, but why? There are a few possibilities, but the only ones I can think of involve how your firmware responds to some commands that only Octolapse typically uses (m400). However, with the problems happening so far after Octolapse takes a snapshot, I just can't see how it could be related, but it obviously is somehow.

I think what is needed is to find another user with an MP 10 who can confirm the same thing is happening to them. If they do NOT have the same problem we could look at some other things (OctoPrint version, fresh OctoPi install, python version, etc...). Alternatively you could roll back to a previous version of the firmware. I assume you are using the latest version, right? I found your version online available for download, but am unsure where the latest version resides, so I can't be sure.

None of the above options are great. What I really need is an MP 10 where I can replicate your issue in a debug environment. However, I will reach out to some OctoPrint experts. Perhaps I can get some additional insights from them. Thanks for sticking by while I try to figure this out! It sounds like this will take a while to fix.

[FormerLurker]

Also, I just re-read this thread (I sometimes discover things I missed) and I noticed that you have tried more than one pi. What versions have you tried (Pi3b+, Pi zero, etc..)? Not sure if it is important or not. Also, have you tried a fresh flash of OctoPi, then ONLY installing Octolapse (I'm grasping at straws here maybe). Lastly, are you running on python 2 or 3? Just trying to find anything at all unique about your setup besides your printer (am not 100% sure anyone has actually used it successfully with this version).

[rvarella75]

So I can tell you this is the second MP10 I've tried. The first one had to be replaced but the same would happen before it broke and got replaced.

The firmware is the same it has been shipped with and it's the only one they have. Probably the same one you found online: https://downloads.monoprice.com/files/firmware/34437_Firmware_191206.zip

Wish there was a custom firmware to try but could not find anything.

The PI I'm currently testing it is a P4. Tried on a P2 as well and I have tried the clean install with Octolapse only before and got the same thing :) unless you think it could make a difference trying with v4.0 since tried with the RCs only.

My Python version is 2.7.16. Will update to 3 now and will let you know what happens in a few minutes.

[FormerLurker]

Thanks for the education regarding the MP10. Believe it or not i have only ever owned one printer, an MK2, so I don't really have any experience with anything else. I am very curious to see if your python 3 change works. Be sure you install python3 dev (see installation instructions on the octolapse wiki for info).

Can you load marlin2 on the Mp10? If so, that would be the ultimate test.

Also, maybe try the classic layer change trigger at some point. It has been only slightly changed in V0.4, and if that works it would give me some insights into what exactly is going on .

[rvarella75]

Too late 😳 I have installed 3.8.3 :0 is it going to break it? Sorry I was just too excited to try something new. Running a new test now. I will let you know

I had looked into marlin2 before but could not figure out how to load it. Will look at it again and try to figure out how to do it.

[FormerLurker]

No problem, lol! Also, i can help with the marlin 2 config if it becomes necessary.

[rvarella75]

Well Python was not the silver bullet. I was really hoping it was.

serial.log octoprint.log plugin_octolapse.log

[FormerLurker]

Crap. I've been reading about installing marlin, and it looks like your board doesn't have a bootloader, so it won't be easy. Let me ponder this and see if I can come up with any ideas....

[rvarella75]

Other things I have tried:

Changing USB cables Changing PI power supply Connecting the camera to a powered hub Drinking

[FormerLurker]

Drinking

I'm with you there, unfortunately :) Seriously though, maybe take a break for a while and I'll do some research. You could try the classic layer trigger too and see if that has any effect, but don't sweat it too much. Eventually the cause will be determined, be it Octolapse, firmware or other.

[rvarella75]

Crap. I've been reading about installing marlin, and it looks like your board doesn't have a bootloader, so it won't be easy. Let me ponder this and see if I can come up with any ideas....

It does not have an ISCP either so I guess I'm a monoprice hostage.

[rvarella75]

So I've run another test with Octolapse disabled. I confess I had never looked into the octoprint log after a successful print. The answer may be Octolapse does not let Octoprint simulate the ok to continue?

| Send: N58848 G1 X160.754 Y150.357 E1626.3031691 | Recv: ok N58837 P0 B0 | Send: N58849 G1 X160.699 Y150.704 E1626.3148584 | Recv: ok N58838 P0 B0 | Send: N58850 G1 X160.585 Y151.281 E1626.3344181 | Recv: Error:checksum mismatch, Last Line: 58843 | Recv: Resend: 58844 2020-06-15 17:11:11,113 - octoprint.util.comm - INFO - Firmware didn't send an 'ok' with their resend request. That's a known bug with some firmware variants out there. Simulating an ok to continue... 2020-06-15 17:11:11,118 - octoprint.util.comm - INFO - Ignoring resend request for line 58844, that still originates from lines we sent before we got the first resend request 2020-06-15 17:11:29,184 - octoprint.util.comm - INFO - Got a resend request from the printer: requested line = 59324, current line = 59330 | Last lines in terminal: | Recv: ok N59311 P0 B0 | Send: N59322 G1 X159.975 Y150.9 E1633.9369892 | Recv: ok N59312 P0 B0 | Send: N59323 G1 X159.635 Y151.127 E1633.9505789 | Recv: ok N59313 P0 B0 | Send: N59324 G1 X159.227 Y151.209 E1633.9644186 | Recv: ok N59314 P0 B0 | Send: N59325 G1 X158.79 Y151.123 E1633.97923108 | Recv: ok N59315 P0 B0 | Send: N59326 G1 X158.696 Y151.069 E1633.9828389 | Recv: ok N59316 P0 B0 | Send: N59327 G1 X158.214 Y150.747 E1634.0021181 | Recv: ok N59317 P0 B0 | Send: N59328 G1 X157.985 Y150.405 E1634.0158105 | Recv: echo:Unknown command: "snap" | Recv: ok P0 B0 | Recv: ok N59318 P0 B0 | Recv: Error:checksum mismatch, Last Line: 59323 | Send: N59329 G1 X157.904 Y150 E1634.02954*72 | Recv: Resend: 59324 2020-06-15 17:11:29,190 - octoprint.util.comm - INFO - Firmware didn't send an 'ok' with their resend request. That's a known bug with some firmware variants out there. Simulating an ok to continue... 2020-06-15 17:11:29,195 - octoprint.util.comm - INFO - Ignoring resend request for line 59324, that still originates from lines we sent before we got the first resend request 2020-06-15 17:11:29,206 - octoprint.util.comm - INFO - Firmware didn't send an 'ok' with their resend request. That's a known bug with some firmware variants out there. Simulating an ok to continue... 2020-06-15 17:11:29,212 - octoprint.util.comm - INFO - Ignoring resend request for line 59324, that still originates from lines we sent before we got the first resend request 2020-06-15 17:11:40,231 - octoprint.util.comm - INFO - Finished in 2754.607 s. 2020-06-15 17:11:40,232 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Finishing" 2020-06-15 17:11:40,237 - octoprint.printer.standard.job - INFO - Print job done - origin: local, path: CFFFP_impossiblepyramid.gcode, owner: 8piweb 2020-06-15 17:11:49,254 - octoprint.util.comm - INFO - Changing monitoring state from "Finishing" to "Operational" 2020-06-15 17:12:42,776 - octoprint.server.util.flask - INFO - Passively logging in user 8piweb from ::ffff:192.168.1.30 2020-06-15 17:12:42,778 - octoprint.access.users - INFO - Logged in user: 8piweb 2020-06-15 17:12:44,167 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:192.168.1.30 2020-06-15 17:12:44,260 - octoprint.server.util.flask - INFO - Passively logging in user 8piweb from ::ffff:192.168.1.30 2020-06-15 17:12:44,261 - octoprint.access.users - INFO - Logged in user: 8piweb 2020-06-15 17:12:45,067 - octoprint.server.util.sockjs - INFO - User 8piweb logged in on the socket from client ::ffff:192.168.1.30 2020-06-15 17:12:45,851 - octoprint.util.connectivity_checker - INFO - Connectivity changed from offline to online 2020-06-15 17:12:45,902 - octoprint.plugins.pluginmanager - INFO - Loaded plugin repository data from disk, was still valid 2020-06-15 17:12:46,749 - octoprint.plugins.pluginmanager - INFO - Loaded notice data from disk, was still valid 2020-06-15 17:12:46,839 - octoprint.plugins.softwareupdate - INFO - Saved version cache to disk

[FormerLurker]

That may well be it, fantastic deduction. Let me ask @foosel about the possibility that the job_on_hold lock may prevent a simulated OK.

[rvarella75]

Tried with the classic layer trigger and also tried turning off LIN_ADVANCE using M900 K0 in the start script but did not work. serial (12).log plugin_octolapse (21).log octoprint (19).log

[FormerLurker]

I think the force OK thing really may be the issue.

[foosel]

Let me ask @foosel about the possibility that the job_on_hold lock may prevent a simulated OK.

That should not be possible. job_on_hold merely influences the job loop (read line from file & send it), the ok simulation happens by setting an internal flag that doesn't even have anything to do with that.

[FormerLurker]

Thanks for chiming in @foosel! I came to the same conclusion myself when I was thinking about this last night. Some of the stalls are happening in-between snapshots without ``job_on_hold```, so that can't be the cause. It's obviously something that Octolapse is doing though. I also realized I can test this with the virtual printer (I believe anyway, feel free to correct me here), so I'm planning on going through that process soon.

[FormerLurker]

@rvarella75, haven't gotten around to this problem yet, but it's still on my radar. Wanted to give you a quick update to let you know I'm still around.

[rvarella75]

No worries. I understand it's not an easy one to fix. Wish there was a way to try a different firmware.

[FormerLurker]

Thank you for your understanding! I would like to get this licked. I've verified that I can test this with the virtual printer, but it takes some setup. I'm 99% sure it can be dealt with!

[bricekevin]

Hello checking in here, I have the following 2x of each

• octoprint 1.5.3
• octolapse 0.4.1
• Monoprice MP10s
• Raspberry Pi 3s
• pi cameras

All are hooked up to a UPC power supply battery back up with proper power supplies and quality USB cables. When I start a print on both printers (different print files) with octolapse enabled, both prints freeze at the same time. Here is the terminal output of one right before the freeze

Send: N18417 G1 X154 Y140.304 E740.377766 Recv: ok N18417 P0 B5 Send: N18418 G1 X155.079 Y142.065 E740.44081103 Recv: ok N18418 P0 B5 Send: N18419 G1 X155.279 Y142.117 E740.44713108 Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves. Send: N18420 M10540 Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves. Send: N18421 M10541 Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves. Send: N18422 M10542 Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves. Send: N18423 M10543 Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves. Send: N18424 M10544 No response from printer after 6 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves. Changing monitoring state from "Printing" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)" Connection closed, closing down monitor

[InvalidCommand]

I'll add that I'm also having this issue.

MP10 Mini - Same hardware as the MP10, just smaller build plate RPi 3B+ OctoPi 0.18.0 OctoPrint 1.6.1 Octolapse 0.4.1

I've used Cura 3.3.1 (last version that has a profile for my printer) and Cura 4.9.1 (set up as a Creality Ender 3).

I've tried files from both versions and they both end up timing out when using Octolapse. Same file prints successfully with it disabled. Please let me know if there's anything I can provide to assist.

[FormerLurker]

This is a tricky one. I am going over this issue again to see if I missed anything obvious.

[jclima]

I have the absolute same issue. What I noticed was that it also happens when just using the normal Timelapse function in octoprint so not sure it is an octolapse issue. I just now started digging but it looks like the pi resets the serial connection with the printer and that halts the job, maybe due to power draw from webcam? Will add more info later on but curious if anyone solved this before I spend a ton of time on it.

[FormerLurker]

@jclima, this could be a power issue, which would explain why it's so damn hard to track down, lol! If it's happening in the stock plugin too, you can bet it's a deeper problem that just an issue with Ocotlapse.

[ejdprops]

Has there been any more movement on tracking this down? I'm having this same problem but only when Octolapse is enabled on my Wyze camera (with webcam firmware flashed) even with the Wyze being powered by a seperate 5V power supply. The problem doesn't occur when I have the regular timelapse enabled, only Octolapse.

[talandaw]

+1 to also having this issue so commenting for tracking. I can provide logs as well if it's helpful!

[michsart]

I'm experiencing this on a Voxelab Aquila X2 (H32). Here's my setup: alexqzd's v1.3.6 for H32 beta 2 firmware (https://github.com/alexqzd/Marlin-H32/releases/tag/v1.3.6-beta-2). Specifically, BLTouch-5x5-HS-H32.bin. OctoPrint 1.8.6 in Docker, composed from the official image in the DockerHub registry. Octolapse 0.4.1. Dell UltraSharp 4K Webcam (WB7022), streamed via the bundled mjpeg-streamer.

Plugins: Bed Visualizer (1.1.1) OctoEverywhere! (1.10.8) Octolapse (0.4.1) OctoPod Plugin (0.3.14)

[BurtBaccarat]

Has anyone come close to figuring out what is causing the freezing? I’m experiencing the same thing with random freezing while using octolapse…. Monoprice mp10

[KlutchKyle]

I’m having the and issue MP10 Mini :(

[KlutchKyle]

Update: So I got octolapse to work on my MP10. What I did was set it’s trigger method to Classic - Gcode and then I went into post processing on Cura and added the Time Lapse post processing. Next, I changed the snapshot gcode to SNAP, and it works!! edit: I think it has something to do with the smart trigger on octolapse.

[FormerLurker]

Has anyone had this issue when not using the 'classic' triggers (not the 'smart' ones)??

Also, you might want to try updating to the latest release. There are a few changes in there. Who knows, maybe we got lucky?