Closed Shadowen closed 6 years ago
And here's the log of a 3 layer bigger peice after the changes...
@FormerLurker I think you solved the issue! Whoever Opened this thread first, try to switch to M83 in your starting code and tick Relative extrusion in your settings. No need to put 1-2-3 seconds delays on the camera 👍 plugin_octolapse (2).log
Now I'll install my E3D V6 I just received, struggle to make everything work and then once I got that done, will retry a full print with Octolapse and enjoy the amazing timelapse
Edit: Should I uninstall the Devel and reinstall the original one? Or you actually fixed something in there instead of just telling me to setup my stuff properly... huhu
Awesome! Very glad we have a workaround. Maybe someone else here can confirm?
@Xenomorphdelombre, If i can't recreate this issue myself, maybe later you could try out the failed gcode (absolute extrusion) after I come up with a solution to the original problem (g92 triggering snapshot early via position response)? I'll update this thread when I've made some more progress.
Grr, was going to try it but now I just keep getting driver errors (short to ground (coil A)) on my extruder. Starting to regret these TMC2130s
The result: https://youtu.be/xo98SDQOdy0
Maybe someone else here can confirm?
I've not had successful stabilized timelapses before, particularly for larger prints. Looking great after switching to relative extrusion distances in Octoprint 1.3.8 / Octolapse 0.3.1.
@Billiam, thanks for the confirmation! That's a nifty timelapse you got there :)
I believe I have a solution for this issue which should be ready to test soon (this evening or tomorrow if things go well). This will hopefully fix the problem of unexpected position reports from G92s or any other random commands.
@FormerLurker great work btw. I'm still running the last devel version. Let me know when it's pushed and I'll update and test. Also, see the result after switching on E3D https://youtu.be/7R22rCrLvDQ
Took me a while to get this think running again on E3D... But it's worth it
Oh also, is the Devel version you provided me the reason my print percentage is not accurate? On a long print, it tells me I'm at 50% when It's almost done.
I'm not aware of any problems with the progress bar, but I haven't paid attention. I'll check it out next time I run a longer test.
Try a few prints with and without Octolapse running and let me know if the problem only occurs with Octolapse enabled please?
Switching M82 to M83 and checking the box to use relative E coordinates in Simplify3D did the trick. https://youtu.be/QaQtq5imQW8
Ok, the latest development version of Octolapse should have this bug pretty much licked. I've added a new flag that gets set right before Octolapse sends any M114s to the printer, and is reset after the position is received. There is still some small but realistic chance that a race condition could still exist, but the odds of it occurring should be dramatically reduced.
Here is the install url: https://github.com/FormerLurker/Octolapse/archive/devel.zip
I'd REALLY appreciate it if someone here still has one of the gcode files that failed to stabilize, and could install and re-test it with the above branch installed (full diagnostic mode please!). Since the issue is caused only by chance positioning of the G92 command and a little bit of bad luck, I'm not sure my own tests are completely valid.
Thanks everyone!
The work around is functioning. I'm going to run a longer (taller) print, but the test cube timelapse looks as good as I've seen. Video and log files are in the shared Dropbox folder.
Dropbox folder with log files. https://www.dropbox.com/sh/uj003q0bkyt43mh/AACOvQ5ZXGAdRaq65IoAfiUMa?dl=0
Anet A8 / Marlin 1.1.7. / Octoprint 1.3.8
@Boymeetsmill, did you happen to upgrade to the latest version on the devel branch today? If so, maybe you could try the original gcode (absolute extrusion) on the newest branch? I'm hoping it will work WITHOUT the workaround now :)
Also, FYI, I believe I have confirmed issues with OctoPrint v1.3.9 and Octolapse. Please stay on v1.3.8 for the time being, thanks!
@FormerLurker Its whatever version is loaded in the Devel branch as of earlier today. I will rerun the cube with absolute extrusion before I go to the big print.
@Boymeetsmill: Excellent, thanks! That update should solve the problem. I made a few changes later in the day that probably won't affect your test at all, but feel free to upgrade (should work without uninstall)!
@FormerLurker Calibration cube ran fine with absolute coordinates. Going to run a long print that has also failed to synchronize previously. Link to the video is below, I accidentally deleted the log file.
https://www.dropbox.com/sh/bpvu7d3ff8xc4hl/AADbttmoK1wRH3Dix729pzrla?dl=0
Fantastic! If it worked, no logfile is necessary. Here's hoping the long print works as well!
Hey FormerLurker,
thank you for your work!!! Found this thread today.. I wonder what I did wrong all the time because of the stabilisation. So I hope there is a new release soon?
Had the problems like the others: Octoprint 1.3.8 raspi 3 CR10-s (Marlin)
With high delay it seems to work as far as I can see in the preview.
How can I install the newest dev-version? For the case I can't wait anymore :D (found the link, sorry. will test it)
@pyro1989, it is easy! In Octoorint go to the plug-in manager, click 'get more' (or something similar) and use this install url: https://github.com/FormerLurker/Octolapse/archive/devel.zip
Thank you. So much better with short delay. Preview is looking good so far (150ms delay) Maybe I need to set a fix focus >.< but that is just a little issue.
So I can't find the original g-code of the failed files. But I sliced the files with nearly the same settings, and the sync was fine on a tall print, video link below.
https://www.dropbox.com/s/4odz75rwbcyznzd/vcl-american-crow-skull_fixed_20180709084255.mp4?dl=0
@Boymeetsmill, thank you so much! I think that's enough confirmation regarding this problem! I'm going to leave the issue up until the next release is deployed so others might find it if they have problems.
Can't you cut an early release or release a hotfix (v0.3.1-1 or something)? That way, users experiencing the problem who aren't on the thread, and new users can avoid having this issue.
@SystemDisc, Yes, I was afraid someone would ask for that :) I'm still pretty green regarding how to handle releases for a project like this, and appreciate the suggestions/nudges. I'll see what I can do, but it might take some time.
I'm not familiar with how releases work with OctoPrint plugins. If it's not possible, it's not a big deal. I'm glad a fix is coming in the next release 😄
Hi FormerLurker, I performed another print after we spoke on youtube and updating to 0.3.2 seems to solve the jerking issue that happened again. Log is 163 mb... Zipped it to 13 MB so... https://www39.zippyshare.com/v/XA9jMEfv/file.html
Thank you for that! Insert sigh of relief here...
Her @FormerLurker As we discussed in reddit, I have updated the plug in but still getting the issue. Here is my config: https://pastebin.com/vJqmtz92 here is the gcode: https://pastebin.com/eR9H998Z And this is what I see when I check the plug in in Software Update: Please let me know hat else can I do to help
@merlindk, it looks like there was an install problem. You should be on v0.3.3:
The version number on the octolapse tab should show 0.3.3:
To make things easier, go to the plugin manager and install from this latest development version and you can be my guinea pig: https://github.com/FormerLurker/Octolapse/archive/rc/devel.zip
That version works better with the software update plugin and allows you to install release candidates from the software updater (different from the plugin manager!) when you are tracking stable release candidates. All you should have to do is paste in that url into the plugin manager and reboot when prompted. Again, make sure you are on the latest release candidate of octoprint!
Check your installation log, and if you see any problems paste it in here. I'll wait to run your gcode through until you try this, ok?
@merlindk, one more thing. Make sure you clear your browser cache after you load the new version. ctrl+F5 usually works for this.
Ok, got it working on the guinnea pig branch. Starting a print now.
it works!!! I love you!.
@merlindk, I think you should reinstall Octolapse from this link: https://github.com/FormerLurker/Octolapse/archive/v0.3.3rc2-dev.1.zip
I fixed some issues with the software update plugin. Hopefully now you should get updates based on your settings now! Unfortunately it doesn't yet work with commit level tracking, but I'll work on that soon!
@merlindk, I keep breaking the versioning because I don't quite understand how OctoPrint does it :)
In the menawhile, just install from here instead: https://github.com/FormerLurker/Octolapse/archive/rc/devel.zip
Looks like its working for me. I'll keep running additional tests. Thx!!!
I finally put my printer back together and it looks like the issue is fixed (at least in devel) for me and everyone else experiencing it. Feel free to close whenever!
Excellent @shadowen! I'll close it next time I'm near my PC, this app seems to have no option to do so.
I dub this issue closed!
@FormerLurker When will you be releasing a version of Octolapse that includes this fix? Octoprint still shows v0.3.1 in the plugin manager.
@systemdisk, I made some amateur mistakes and ended up adding too many features at once, delaying a full release. I've since frozen the development of new features and am concerned 100% in pushing the new version to master. I've got a pre-release out now and hope to soon move it to release candidate status.
If you or any of your friends are interested in helping me test, you can install via the plugin manager using this url: https://github.com/FormerLurker/Octolapse/archive/v0.3.4rc1.dev2.zip
Please report any issues here: https://github.com/FormerLurker/Octolapse/issues/232
Fyi, in this version you can track development, release candidate, and stable builds via the software update plugin!
Sorry for any typos, on my phone.
If this is a feature request describe it here
My snapshots aren't stabilized properly. The printer is still doing the stabilization movement, but the snapshot appears to be taken at the wrong time.
Version of Octolapse
Octolapse Version: Octolapse v0.3.1
Version of OctoPrint
OctoPrint Version: OctoPrint 1.3.8
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
Run OctoLapse-enabled print. Settings as below.
What should have happened?
Stabilized print at printer's rear-left corner.
What happened instead?
Stabilization occurred, but snapshots were happening while the extruder head was still on the print, rather than in the corner. Likely snapshots were mis-timed.
Operating System running OctoPrint and Octolapse
OS Name: OctoPi Os Version: OctoPi 0.14.0
Printer model & used firmware incl. version
Printer Model: Maker Select v2.1 w/ RAMPS v1.4, Chimera toolhead (dual extrusion) Entire print executed with T1 (second tool). This may be relevant as T0 is unheated/unused throughout the entire print. Printer Firmware Version: Slightly modified Marlin 1.1.x (bugfix branch)
Link to the gcode file you were printing when the problem occurred
Link to Gcode File: CuteOcto.gcode
Link to settings.json
Link to settings.json with all passwords removed: Settings.json Stabilization: Fixed - Extruder at Back Left (default) X: Relative Coordinate 1% Y: Relative Coordinate 99% ??? What are relative coordinates?
Link to plugin_octolapse.log
Link to plugin_octolapse.log: octolapse.log
Link to octoprint.log
Link to octoprint.log: octoprint.log
Screenshots and/or videos of the problem:
Screenshot/Video Links: Attempt 1 - stabilization fails halfway through. Print was done in Vase mode. Gcode not provided. It's not clear which file the logs pertain to. Video - stabilization never occurs. Print was done in normal mode (0.18 first layer height, 0.2 layer height). Print is sliced at 50% size.