Unable to get stabilized timelapse

[zymbiosis]

Version of Octolapse

Octolapse Version: v0.4.0rc1.dev4

Version of OctoPrint

OctoPrint Version: OctoPrint 1.3.12 running on OctoPi 0.17.0 H

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

Attempting to print any print and get stabilized output. After reading some other issue threads, I tried setting my Start Script to M83 (already had "Relative Extrusion distances" checked in S3d). All plugins (except necessary GPX plugin) have been disabled. I even tried bumping the delay up to 5000 but it still seemed inconsistent.

What should have happened?

Stabilized images

What happened instead?

Ugly timelapses :(

Operating System running OctoPrint and Octolapse

OS Name: OctoPi Os Version: 0.17.0 H

Printer model & used firmware incl. version

Printer Model: Flashforge Creator Pro 2016 Printer Firmware Version: That I'm not 100% on...let me know if it's necessary

Browser and version of browser, operating system running browser

Browser: Chrome (latest) Browser OS: Windows 10

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

Link to Gcode File: https://gist.github.com/zymbiosis/32a57155ee5c6cf7cfa895785406c22a

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: https://gist.github.com/zymbiosis/420080910d2eecc1b53718dcb7b2c820#file-plugin_octolapse-log

Link to octoprint.log

Link to octoprint.log: https://gist.github.com/zymbiosis/420080910d2eecc1b53718dcb7b2c820#file-octoprint-log

Also, including a serial log as well since it sounds like that may help https://gist.github.com/zymbiosis/420080910d2eecc1b53718dcb7b2c820#file-serial-log

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

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]

Can you post a video so I know what you are seeing? Also, your settings.json file would be most helpful. It is super easy to export:

[zymbiosis]

Oh those settings, sure thing! https://gist.github.com/zymbiosis/420080910d2eecc1b53718dcb7b2c820#file-settings-json

As for the video, they all pretty much end up like this: https://drive.google.com/open?id=1wFGri2CiYrWzA-BpMzS9wJhES29sYO8s

The closest I got was setting the delay to 5000 and some of the snaps were in the correct (back left) location.

Appreciate your work and help!

[FormerLurker]

Hmm.. it's looking like your printer doesn't support the M400 command, and instead uses an alternative command (G4 P0) to accomplish this. I may have to add a new setting to get things working on your printer, which will have to wait until this current release candidate gets promoted. This is mostly because Octoprint 1.4.0 just dropped, and the current master release isn't compatible, which is a bummer.

Perhaps you could also request that the printer MFG adds support for the M400 command, or at least verify for me that M400 isn't supported, and that G4 P0 is the equivalent command for your firmware?

[zymbiosis]

That seems to be it exactly! It doesn't look like the firmware supports M400, but rather the G4 P0. I tried adding the move command followed by the G4 P0 and snapshot command in my layer change script and it seemed to work. It did cause the print head to stay stationary for a couple seconds, but for sure seems to be the main culprit.

[FormerLurker]

Super clever solution! I've been thinking about fixing this in V0.4, and will respond back when that happens. It wouldn't be too difficult. Plus, I can then add your printer to the profile repository too :)

[zymbiosis]

So, I'm going to try modifying on my octoprint to see if this does in fact fix everything. My quick code check...am I correct in modifying this (https://github.com/FormerLurker/Octolapse/blob/d44129ca5e8f36c6e013aaf5a4b0c5ae9aae5466/octoprint_octolapse/stabilization_gcode.py#L1223) and change it to G4 P0?

Then I can run a test print with my normal settings and see if that works.

[FormerLurker]

That is one place. There are also a few M400s in timelapse.py. make sure you change those too.

[FormerLurker]

Btw, I love your initiative!

[zymbiosis]

You got it. I'll update on my pi and report back the results.

[zymbiosis]

And no problem, glad to help where I can!

[zymbiosis]

That did it! Updating the M400 to G4 P0 in the following locations fixed it (even using a snapshot delay of 0 came out perfect):

https://github.com/FormerLurker/Octolapse/blob/d44129ca5e8f36c6e013aaf5a4b0c5ae9aae5466/octoprint_octolapse/stabilization_gcode.py#L1223 https://github.com/FormerLurker/Octolapse/blob/d44129ca5e8f36c6e013aaf5a4b0c5ae9aae5466/octoprint_octolapse/timelapse.py#L266-L267 https://github.com/FormerLurker/Octolapse/blob/d44129ca5e8f36c6e013aaf5a4b0c5ae9aae5466/octoprint_octolapse/timelapse.py#L290

The video is stabilized and the print head only stays in the snapshot location for maybe a fraction of a second now.

https://drive.google.com/open?id=1NvGhthcRKsTE6R1X16IQo42MXgzgGids

[FormerLurker]

Awesome!! Now we know tye change will work when I add a printer profile setup. So, I am thinking of adding a dropdown to the firmware settings within the printer profile for this. What do you think?

On Sat, Mar 7, 2020, 10:21 AM zymbiosis notifications@github.com wrote:

That did it! Updating the M400 to G4 P0 in the following locations fixed it (even using a snapshot delay of 0 came out perfect):

https://github.com/FormerLurker/Octolapse/blob/d44129ca5e8f36c6e013aaf5a4b0c5ae9aae5466/octoprint_octolapse/stabilization_gcode.py#L1223

https://github.com/FormerLurker/Octolapse/blob/d44129ca5e8f36c6e013aaf5a4b0c5ae9aae5466/octoprint_octolapse/timelapse.py#L266-L267

https://github.com/FormerLurker/Octolapse/blob/d44129ca5e8f36c6e013aaf5a4b0c5ae9aae5466/octoprint_octolapse/timelapse.py#L290

The video is stabilized and the print head only stays in the snapshot location for maybe a fraction of a second now.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/Octolapse/issues/466?email_source=notifications&email_token=AH6RJOET2XMU4YE3HW5LBQ3RGJX7HA5CNFSM4LBUWIAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOD5MHQ#issuecomment-596104734, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH6RJOFEGOGRZWXTWAIL6OLRGJX7HANCNFSM4LBUWIAA .

[zymbiosis]

Yep I think that makes perfect sense!

[zymbiosis]

Something to add as I've been printing some items... I had been using the gcode command to trigger the snapshot. I just tried the "Smart Trigger" on high quality. It paused on the infill for a few seconds, then went to the snapshot position and back, then waited another couple seconds before starting again. Not sure if that's related to this issue or not, but wanted to bring it up just in case. Let me know if you want logs, or a separate issue.

[FormerLurker]

Probably a separate issue. Does it always happen, or just once? If you can catch it in the act with debug logging enabled, that would be very helpful.

[zymbiosis]

Happens every layer. I'll catch a log and post a separate issue

[FormerLurker]

Hmm. Could be a problem with P4 G0. I wonder is you could create some test gcode that includes G4 P0 in the middle of some moves and see if you get a delay. They should all be relatively short moves so you are sure the buffer is filled. I know klipper can introduce some extra delay when using M400 (more than marlin), so maybe this is an issue with your firmware? In any case if you can reproduce it without octolapse that would make me happy. If that happens I would be more than happy to help you report the issue to the mfg.

Also, did you remember to turn your camera delay down to 0? Just in case....

[FormerLurker]

Also, it could be a subtlety with the code changes you made. Next weekend I will make a special branch of Octolapse including the G4 P0 code option so you can test it. However, from what I can see you did exactly what We would have done.

[zymbiosis]

Ok, so I've finally been able to work on some more troubleshooting. First off, I'm dumb and the delay was because I entered the retraction settings as 40 (thinking mm/sec instead of mm/min). So after brining that up it doesn't pause anymore.

I did try updating the latest code (since a few versions have passed since this issue was originally opened). I can confirm that changing the 4 lines from above do still allow the snapshots to be captured as expected. I'm not too familiar with octoprint plugins, but I may try to poke around and see if I can add in an option to the printer profile for selecting between the two codes and submit a pull request...but we shall see.

Another issue I found, and not sure if you want me to create a separate issue or not, but Z hop seems to be causing an issue with my printer. I'm pretty convinced this is a firmware issue but maybe you have some insight. Essentially when trying to do a z hop the printer moves in the X direction like 40mm or so before doing any other moves. Ive narrowed it down where these three lines cause the printer to act normal vs the weird x movement

G91
G1 Z1.000 F1200.000
G90

See a video of what I'm talking about here: https://drive.google.com/file/d/1iqGiYf_mmKzJ55ei2JB8GZQhxA3_BoUe/view?usp=sharing

[FormerLurker]

Sorry I've not been able to add the option to change the 'wait for moves to complete' gcode, but I WILL get to that.

I'm having a hard time understanding how that code would result in any x or y motion. Perhaps you can run Octolapse with debug logging and paste in a sample log of the snapshot commands that lead to the problem?

[zymbiosis]

Ok, so after a LOT of testing and trial and error I narrowed down the weird issue with the X movement to be related to how the firmware handles the different extruder offsets. Essentially relative movements to the Z axis while using the secondary extruder caused unwanted x travels. This does appear to be a firmware bug. However in realizing this and looking through to see how I could still use this with octolapse, I discovered that by setting the "Snapshot Gcode Axis Compatibility Mode" to DISABLED (unchecked) allowed everything to function as expected including the z-hops. I would be more than happy to provide my printer configuration to be used as a template for the Flashforge Creator Pro once we can get the options for G4 P0 sorted out. I should be able to take a look at the code this week to see if it's something I'm comfortable changing and providing a pull request for.

[FormerLurker]

Wow, that in insane. Lots of firmware problems. It would be nice if there was one gcode standard....

I've been putting off the alternative 'wait for moves to finish' command option for long enough. I did an initial search, and it doesn't really look like it will be too complicated. The settings repository will be the biggest pain, but not too bad either. I'll try to put together a quick and dirty build so you can test it, and it can be refined before the next release. Bug me if you don't hear back before next week.

[SnowLeopard71]

Hi, I just started using Octoprint and Octolapse yesterday and have concluded that my Labists ET4 (clone of Anet ET4) does not support the M400 command either. I was quite confused at first. I thought the problem was camera timing, but while trying to watch the debug output in log, terminal output, and the motion of the printer, I realized there was a 5 or 6 second delay between the snapshot commands in the logs and the head moving to back right position. I had come across the fact that the ET4 did not previously support the M114 command (which works fine on mine), and when I saw it used along with the M400, I decided to test M400 too. I sent a slow move command followed by M400 which returned ok instantly instead of after the movement had finished.

I changed the M400 to G4 P0 in stabilisation_gcode.py and timelapse.py and immediately noticed a difference, just as @zymbiosis reported.

Octopi 0.18.0 Octoprint 1.5.3 Octolapse 0.4.1

It occurred to me that testing whether M400 works is relatively simple: M114 will not return the correct destination coordinates if it is not blocked by a working M400 command, not to mention an instant ok response after a move that should take a minimum amount of time should be considered abnormal probably.

[FormerLurker]

@SnowLeopard71, 100%. There are some other firmwares that use different commands too. I'm actively working on this modification, fyi.