Octolapse: Snapshots not stabilized.

[Shadowen]

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.

[ejjenkins]

I had the same problem on one of my printers...I increased the snapshot delay in the OctoLapse camera settings and it fixed it for me...I went to 250ms from the default 125ms.

[Shadowen]

I thought that Octolapse should fill the printer's command buffer somehow to ensure the command is executed correctly... See https://github.com/yschaeff/slic3r_post_processing/blob/master/slic3r-post.py for how someone else implemented the movement portion.

[FormerLurker]

Is the printhead moving to the correct location, but the snapshot is being
taken at the wrong time? If so, I have heard of some other cases of
unusually large snapshot delays being necessary to get a stable video. I'm
investigating but am having a hard time reproducing. I'll get to the
bottom of this soon hopefully.

If the printhead is not moving to the right place, let me know and I'll get
back to the drawing board.

In any case I'll take a closer look in the morning.

On Fri, Apr 20, 2018, 6:13 PM Wesley Heung [e-mail] wrote:

I thought that Octolapse should fill the printer's command buffer somehow
to ensure the command is executed correctly... See
https://github.com/yschaeff/slic3r_post_processing/blob/master/slic3r-post.py
for how someone else implemented the movement portion.

—
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/149#issuecomment-383245063,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Af0UuPqz4kzHH6d_SysGbiwp0VYPRxkuks5tqmuTgaJpZM4TeKMQ
.

[Shadowen]

I'm seeing the print head move to the correct location, but the snapshot doesn't even seem to be "off by a bit" - it seems to be taking the snapshot without even waiting for the printhead to move.

I'm thinking that OctoLapse isn't waiting for the move command to finish executing before it triggers the snapshot, but I'm not exactly familiar with how the snapshots are triggered.

Thanks for looking into it!

[FormerLurker]

It is probably taking too long to acquire the snapshot, and is grabbing a
frame after returning to the start location. Try this as a test. Set the
delay (camera profile) to 3000 and run a short test print and let me know
how the timelapse looks. If that fixes it maybe you can help me debug
further?

On Fri, Apr 20, 2018, 11:06 PM Wesley Heung [e-mail]
wrote:

I'm seeing the print head move to the correct location, but the snapshot
doesn't even seem to be "off by a bit" - it seems to be taking the snapshot
without even waiting for the printhead to move.

I'm thinking that OctoLapse isn't waiting for the move command to finish
executing before it triggers the snapshot, but I'm not exactly familiar
with how the snapshots are triggered.

Thanks for looking into it!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/FormerLurker/Octolapse/issues/149#issuecomment-383266016,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Af0UuPIBj2qpINMqMO122Ksx_PMz4kcoks5tqrA9gaJpZM4TeKMQ
.

[Shadowen]

I'll give that a shot tomorrow and see what I can come up with. Thanks!

[Shadowen]

Looks like that does the trick (mostly).

I suppose the correct solution would be to wait for the snapshot to finish (image capture) before resuming the print? I'll see if I can do that when I have some free time.

[vertigo235]

I have the same issue, it use to be I could only do "center", and that would work most of the time, now even that doesn't work sometimes. I'll try increasing the delay.

[FormerLurker]

@Shadowen and @vertigo235, I will try making the snapshot acquisition routine synchronous and we can see if that helps at all.

[m2oore]

Am having the same problem moving the delay to 3000 ms seems to have fixed it some. Get a little bit of the head not completely moving to its position before taking snapshot. Will try higher then 3000 ms but thats a heck of a delay =)

Update:
I had to put my delay to 5000ms and it works well now in test mode will try a calibration cube and see how that works now.

[FormerLurker]

That is a very large delay.. too much. What hardware are you running, including your camera? Also, what resolution and framerate is your camera?

[m2oore]

Running CR-10S
Using Th3d U1.R1.6 Firmware
Camera is a Logitech C270
Resolution: 1280x720 Framerate: 30

Also, running it at 5000ms got a perfect timelapse

TimeLapse

[FormerLurker]

@m2oore, raspberry pi? If so, what model. Octopi? Sorry to be so nosy, lol!

[m2oore]

Yes Raspberry Pi 3 Model B
Octoprint 1.3.8
Octopi 0.14.0

[Boymeetsmill]

Was there any resolution to this issue? I am experiencing the same problem...

I was running 0.31 of Octolapse on 1.3.7RC and everything was fine, but when I upgraded to 1.3.8 the stabilization stopped working. The head will move to the correct place for the stabilization, but the image isn't take right away and is delayed 2-3 seconds, and by the time the image is taken the print head has moved back to printing.

Failed Stabilize Video
https://www.dropbox.com/s/k5ydjna5mbvwlrp/3DBenchy_20180508084205.mp4?dl=0

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?
No I have not done a print with diagnostic logging enabled.

What were you doing when the problem occurred
Just running my Anet A8 printer like I normally would.

What should have happened?
The timelapse should have been stabilized, with the printhead in the fixed in the center of the build tray.

What happened instead?
The timelapse video that was rendered looks like the basic timelapse videos from OctoPrint.

Operating System running OctoPrint and Octolapse
OS Name: OctoPi
Os Version: OctoPi 0.13 and 0.15 (I updated to 0.15 last night and the problem still persists)
Raspberry Pi 3

Printer model & used firmware (incl. version)
Printer Model: Anet A8, stock hardware
Printer Firmware Version: Marlin 1.1.8, with some customization for pausing, and basic speeds and feeds.

Link to the gcode file you were printing when the problem occurred
https://www.dropbox.com/s/p52f5x7snbcoq4j/3DBenchy.gcode?dl=0

Stabilization: Fixed - Extruder Center
X: Relative Coordinate 50%
Y: Relative Coordinate 50%

Link to plugin_octolapse.log
https://www.dropbox.com/s/lp2egnhyp8j0tn5/plugin_octolapse.log.2018-05-08?dl=0

Screenshots and/or videos of the problem:
Screenshot/Video Links:
1) Run last night after my update to OctoPi 0.15
https://www.dropbox.com/s/k5ydjna5mbvwlrp/3DBenchy_20180508084205.mp4?dl=0

[FormerLurker]

@Boymeetsmill, I believe there is a threading problem that affects some specific hardware/firmware combinations that is causing the snapshot delay to be quite high. Try editing your camera profile and turning up the snapshot delay. I recommend doubling it until the image is stabilized.

Progress has been kind of slow for the last month due to some work related issues, so I apologize that this issue hasn't already been dealt with. I hope to have this and some other items fixed as soon as things let up a bit :)

[Boymeetsmill]

@FormerLurker I have tried upping the delay, going to 2000ms almost fixed it. There are two hiccups in the beginning, but overall the time lapse much better.

https://www.dropbox.com/s/hms0y18s7x64x0w/3DBenchy_20180510072801.mp4?dl=0

[FormerLurker]

@Boymeetsmill, I'm glad it's a bit better. 2000MS is way too high, so I'll let you know when I have some new code for you to test.

[a-w]

I can confirm the observed behavior with:

Octolapse Version: 0.3.1
OctoPrint Version: 1.3.8 (installed from source, _not_ from octopi image)
Running on: Rasberry Pi 2 (900MHz)
OS Name: Raspbian
Os Version: 2018-03-13-raspbian-stretch-lite
Printer Model: Anet A6
Printer Firmware Version: Marlin 1.1.8 + autolevel customization
Using octolapse settings:

• printer: Anet A8
• stabilization: fixed - extruder at center
• snapshot: height 0.20mm
• camera: default webcam (RasPi camera)

Timelapse will be stable if and only if snapshot delay is set to 2500ms or higher.

Currently not logging. If it helps, I could provide log files (with the new logging features of 13-May-2018).

[Core3dTech]

same issue here.

Octolapse Version 0.3.1
OctoPrint Version 1.3.8
Raspberry Pi 3
Printer Model: Custom CoreXY (using MK3 profile)
stabilization: fixed - extruder at back
snapshot: layer change
camera: Microsoft LifeCam Studio

[FormerLurker]

It looks like this happens across a wide variety of hardware and software. @mvl03, are you using any other plugins? If so, could you disable all of them except Octolapse and try again? I'm not yet seeing anything that connects all of these cases yet and still have not been able to replicate the problem, which is surprising since it happens consistently for some.

[Core3dTech]

Shoot, I thought I had turned off regular timelapse (but forgot to save). I'll try again with regular timelapse turned off

[Core3dTech]

I changed my delay to 2000ms but I'm pretty sure that later on in the print, I did not see the extruder parked for 2000ms (went backwards and immediately forward again). Not sure if that was the intention

[FormerLurker]

That is very helpful info actually! Hmm, that indicates to me that somehow
either the M400 command is not being sent, or is not being properly
obeyed. Here's how it should happen:

1. Time to snapshot, wait for commands to finish and get current position
   (M400, M114)
2. Move to snapshot position and wait until all movement is finished and
   get position (G1 X?? Y??, M400, M114)
3. Wait for SNAPSHOT_DELAY milliseconds (the printhead should be in the
   snapshot position while it's waiting!)
4. Download image.

My guess is that position from the M114 in step 2 is being immediately sent
back, essentially ignoring the M400. I wonder if there is a way to verify
this. Maybe you can watch the terminal window and see if the response to
the M114 in step 2 comes back before the printhead has moved to the
snapshot location? If so at least we will know what's going on!

Edit: I see that @Shadowen actually noticed this earlier, but I did not notice that he noticed, lol! It seems like this must be a problem with the actual M400 command somehow.

[Core3dTech]

I see the m114 prior to it moving to the back of the bed. Not sure what response to look for. M114 is immediately followed by a G1 command. I should be logging this session, so maybe the logs will tell us more. I did go back to initial delay as I turned off the regular timelapse (seeing if that would help). Keep you posted

[FormerLurker]

@mvl03, the logs will help. If you can get the serial.log file from Octoprint, that might be the best for this situation.

Also, FYI, I'll be out of town until around the 1st of July, so I won't have time to debug further until then, sorry :(

[Core3dTech]

Doh. serial log not enabled. In the meantime here octolapse.log
plugin_octolapse.zip

Starting another print with Serial on

[Core3dTech]

here's the latest vid and log
octolapse.zip

Thanks!!

[SystemDisc]

I think the problem is that the delay is not always respected. I have a delay set as 1000ms and here are a couple videos illustrating the problem:

Delay being sort-of respected: https://photos.app.goo.gl/Zo264HLoSp2dLzgU7
Delay not being respected at all (same print): https://photos.app.goo.gl/j1bjNBg24KkqN2UY8
Resulting not-at-all-stabilized timelapse: https://photos.app.goo.gl/iYFYDXawR57Cmq3T6

[Xenomorphdelombre]

Hey FormerLurker! First of all thank you so much for this plugin! It's AWESOME! Now... I have the same issue... Running the latest and greatest, with a Logitech C920 setup at 720P / 30FPS.

I can see that the screenshot is taken RIGHT BEFORE the printer start moving to go in position. On small prints, it seems to behave ok, but on largers it's out of synch. I'll try to increase the delay too and see how it goes. I have an Anet A8 on Skyned3D. All this runs from a Raspberry Pi 3 B+. I have a couple other plugins loaded... Maybe I can try to uninstall some and see if this is related?

[FormerLurker]

Hi all! I've been looking over @mvl03's logs and I'm pretty confused. I had expected to see M400 not being respected, but it appears as though there's an appropriate delay between M400 and the corresponding OK. The 2000MS delay should be applied right after the response to the M114 command, but the following command was issued only 500ms or so after the M114 response.

Either I'm not calculating the delay properly, or something is up with the timer itself (probably the latter). I may first add some enhanced logging capability to the snapshot itself to gather more data. I'll probably add some additional debug options for testing. I'll let you guys and gals know what I come up with.

Thanks for being so patient!

[Xenomorphdelombre]

Awesome thanks. If you need more details I'd be happy to provide logs as well. I stopped using octolapse because of that. If the delay is low, it's not stabilized, if it's too high, it stay in place for a long time. I think that the settings of speed per layer length might affect? Also maybe the version of Marlij that runs on the device can affect? I'm using skynet3d 2.3.2. I've been thinking to chnage to the latest Marlin firmware... Idk.

[Boymeetsmill]

I can run some more small, or tall prints. I've disabled the plugin
currently as it was affecting print quality, but I would gladly run some
more prints for logs if the sync can be fixed.

On Fri, Jun 29, 2018 at 11:00 AM Xenomorphdelombre [e-mail]
wrote:

Awesome thanks. If you need more details I'd be happy to provide logs as
well. I stopped using octolapse because of that. If the delay is low, it's
not stabilized, if it's too high, it stay in place for a long time. I think
that the settings of speed per layer length might affect? Also maybe the
version of Marlij that runs on the device can affect? I'm using skynet3d
2.3.2. I've been thinking to chnage to the latest Marlin firmware... Idk.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/FormerLurker/Octolapse/issues/149#issuecomment-401429423,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AkENRR3DCO5rDQih6mElDLyDQTnTU1LOks5uBms2gaJpZM4TeKMQ
.

[Xenomorphdelombre]

Anyone has anything new on this? I'm not sure how the screen grab command is sent but I see that the screenshot is taken before its time. Is this because the gcode is buffered in memory and it's hard to know when the action sent will happen? I noticed when I try to manually send a gcode while it's printing its bit instantaneous

[FormerLurker]

Thanks for your interest! I'm working on this now (been away for a while). Look for an update here in the next week. I think it has something to do with my timer thread.

[Xenomorphdelombre]

Amazing! Thank you for your answer. If you need someone to perform tests let me know :)

[FormerLurker]

@Xenomorphdelombre, I definitely need some assistance testing! Can you try re-installing Octolapse from the following URL -https://github.com/FormerLurker/Octolapse/archive/devel.zip

I don't think you'll need to uninstall first. When you try it out please use the 'Full Diagnostic - Live Print' debug mode and save the octolapse.log file. I've added some key logging info that should help us see how long Octolapse is actually waiting, but I don't think this will solve the problem yet.

Also, FYI, there are a few new things (thanks @Shadowen !) in this version: Animated Gif support and fixed and enhanced watermark support. Unfortunately there is some additional junk in this build that I'm not finished with entirely, so it would be a good idea to reinstall the release version when you have a chance (install from https://github.com/FormerLurker/Octolapse/archive/v0.3.1.zip).

Thanks!

Edit - Fix link to devel branch zip

[Xenomorphdelombre]

On it!

Oh the devel.zip file is not available. Is the link wrong?

Edit: Nevermind got it
https://github.com/FormerLurker/Octolapse/tree/devel

[SystemDisc]

Or this: https://github.com/FormerLurker/Octolapse/archive/devel.zip

[Xenomorphdelombre]

Ok so to install it I had to upgrade PIP. Then I could install it. After the install I ran a print that I had a timelapse from before.
With official release: https://youtu.be/tzefiCaWs7Y

With the 0.3.1 devel: https://youtu.be/SATpzJyFHWA

Also, attached the log file to this post.
Edit: Wrong log file uploaded
plugin_octolapse.log

[FormerLurker]

@Xenomorphdelombre, thanks loads for the logs! With that I was able to narrow down the issue to the time.sleep function. For whatever reason it isn't waiting nearly long enough in your case, which is a mystery to me. In order to deal with the problem I implemented a loop that checks to see if the desired delay is elapsed after sleeping (with 1MS accuracy). If not the loop repeats until the delay is achieved. I also added some additional logging which could grow quite large depending on the behavior of time.sleep on your system. I'll remove the extra logging once the problem is fixed.

Can you attempt to re-install from the same path and re-post your logs, even if the tests are a success? Here is the path again: https://github.com/FormerLurker/Octolapse/archive/devel.zip

Thanks!

[Xenomorphdelombre]

@FormerLurker yes, I'm at work right now, I'll see if my wife can turn the printer on and will try to install / print remotely ;)

[Xenomorphdelombre]

Hey here's the log. I only let it go for two layers and I could see that the snapshot happened right away at the end of the layer way before the printer would move to the desired location.
plugin_octolapse (1).log

[FormerLurker]

@Xenomorphdelombre, thanks for trying it out. Once again the log file has proven to be very useful.
The log indicates that approx 0.250 seconds passed as expected, but something else triggered the snapshot early. I have a hunch that the G92 commands used to reset the E axis to 0 are somehow causing your printer to report the current position, which may be triggering the snapshot early! If this is the case your timelapse should work when all of the G92s have been removed, and I'll know where to start working next!

Here are some interesting logs leading me to this conclusion:

2018-07-03 22:06:32,698 Sent to printer: Command Type:None, gcode:G92, cmd: G92 E0, tags: set(['fileline:627', 'source:file', 'filepos:24516'])
2018-07-03 22:06:32,705 Received from printer: line:X:149.80 Y:147.30 Z:0.45 E:0.00 Count X:10265 Y:11688 Z:180
2018-07-03 22:06:32,707 Printer event received:PositionUpdate.
2018-07-03 22:06:32,711 Received from printer: line:ok

In the above a G92 was sent and a position response was IMMEDIATELY provided. Here is another section where the snapshot gcode is being queued:

2018-07-03 22:08:38,856 Position Change - G1 X110.000 Y110.000 F3000 - Absolute Move From(X:70.6,Y:78.1,Z:0.65,E:321.4844) - To(X:110.0,Y:110.0,Z:0.65,E:321.4844) 
2018-07-03 22:08:38,857 Extruder Changed: E:0.0, Retraction:4.5 IsExtruding:False-False, IsExtrudingStart:False-False, IsPrimed:False-False, IsRetractingStart:True-False, IsRetracting:True-False, IsPartiallyRetracted:False-False, IsRetracted:True-True, IsDetractingStart:False-False, IsDetracting:False-False, IsDetracted:False-False
2018-07-03 22:08:38,857 Queuing Command: Command Type:None, gcode:M400, cmd: M400, tags: set(['trigger:printer.commands', 'plugin:octolapse', 'source:plugin', 'snapshot_gcode'])
2018-07-03 22:08:38,858 Queuing Command: Command Type:None, gcode:M114, cmd: M114, tags: set(['trigger:printer.commands', 'plugin:octolapse', 'source:plugin', 'snapshot_gcode'])
2018-07-03 22:08:38,949 Received from printer: line:ok

2018-07-03 22:08:38,957 Sent to printer: Command Type:None, gcode:G1, cmd: G1 Z0.650 F1000, tags: set(['fileline:1166', 'source:file', 'filepos:40627'])
2018-07-03 22:08:38,959 Printer event received:ZChange.
2018-07-03 22:08:38,979 Received from printer: line:ok

2018-07-03 22:08:38,982 Sent to printer: Command Type:None, gcode:G1, cmd: G1 E0.0000 F2400, tags: set(['fileline:1167', 'source:file', 'filepos:40645'])
2018-07-03 22:08:39,135 Received from printer: line:ok

2018-07-03 22:08:39,139 Sent to printer: Command Type:None, gcode:G92, cmd: G92 E0, tags: set(['filepos:40653', 'source:file', 'fileline:1168'])
2018-07-03 22:08:39,156 Received from printer: line:X:70.60 Y:146.90 Z:0.65 E:0.00 Count X:7352 Y:14670 Z:180

2018-07-03 22:08:39,162 Received from printer: line:ok

2018-07-03 22:08:39,164 Printer event received:PositionUpdate.
2018-07-03 22:08:39,165 Sent to printer: Command Type:None, gcode:G1, cmd: G1 X70.600 Y78.100 E2.2654 F3360, tags: set(['source:file', 'filepos:40687', 'fileline:1169'])
2018-07-03 22:08:39,166 Taking a snapshot.

Notice that a position update was received immediately after the G2 command was sent to the printer, even before the M114 command was sent (though it was queued...). I suspect G92 is causing this somehow, though I'm not 100% sure how to handle it ATM.

Would you mind trying something for me? I know it sounds crazy, but can you try to reslice your file using relative E coordinates (you are currently using absolute)? I can help you figure out how to do this if you let me know what slicer you are using. You'll also want to double check your start gcode and see if you find any M82s and switch them with M83 (which cannot be arbitrarily done, so be careful here). Also you'll want to search for G92 commands to make sure that one isn't being placed at the end of each layer. I would be more than happy to review your code, but I suggest you use a very small model so that there is less code to review :)

Thanks for your help thus far!

[Xenomorphdelombre]

Wow! Nice analysis. Ok I'm using Simplify 3D as Slicer.
My Start GCode is the following
G21 ;metric values G90 ;absolute positioning M82 ;set extruder to absolute mode M107 ;start with the fan off G28 X0 Y0 ;move X/Y to min endstops G28 Z0 ;move Z to min endstops G0 Z15.0 F9000 ;move the platform down 15mm G92 E0 ;zero the extruded length G1 F200 E5 ;extrude 3mm of feed stock G92 E0 ;zero the extruded length again G1 F9000

So I'd have to change "M82 ;set extruder to absolute mode" to M83 right? What is the difference in the slicing and whats the effect ?
. If in Octolapse I'd change my stabilization settto fixed at 110mm X and Y (Which is the center of the bed) would it help?

Also After reading on Absolute and relative I guess I also need to change G90 to G91 right? Let me know... I'd like to better understand the difference between the two and what implication it'll havve on my prints.

[Shadowen]

It should have no effect on your prints. It's just a setting telling the
slicer (and your firmware) to generate numbers in increments (X += 1; X +=
1;), as opposed to absolutes (X = 1; X = 2).

On Tue, Jul 3, 2018 at 7:38 PM Xenomorphdelombre [e-mail]
wrote:

Wow! Nice analysis. Ok I'm using Simplify 3D as Slicer.
My Start GCode is the following
G21 ;metric values G90 ;absolute positioning M82 ;set extruder to absolute
mode M107 ;start with the fan off G28 X0 Y0 ;move X/Y to min endstops G28
Z0 ;move Z to min endstops G0 Z15.0 F9000 ;move the platform down 15mm G92
E0 ;zero the extruded length G1 F200 E5 ;extrude 3mm of feed stock G92 E0
;zero the extruded length again G1 F9000

So I'd have to change "M82 ;set extruder to absolute mode" to M83 right?
What is the difference in the slicing and whats the effect ?
. If in Octolapse I'd change my stabilization settto fixed at 110mm X and
Y (Which is the center of the bed) would it help?

Also After reading on Absolute and relative I guess I also need to change
G90 to G91 right? Let me know... I'd like to better understand the
difference between the two and what implication it'll havve on my prints.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/FormerLurker/Octolapse/issues/149#issuecomment-402321335,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIJ8N9Mx6Eh9AwhKHdiF01seLEpmy7IGks5uDAB8gaJpZM4TeKMQ
.

[FormerLurker]

Just change m82 to m83. Your x y z axes should stay fixed coordinates (g90). Did you see the option in simplify for relative extrusion?

[Xenomorphdelombre]

Don't I also have to setup my firmware to relative extrusion?

[Xenomorphdelombre]

So my Starting code would be: G21 ;metric values G91 ;Relative positionning M83 ;set extruder to relative mode M107 ;start with the fan off G28 X0 Y0 ;move X/Y to min endstops G28 Z0 ;move Z to min endstops G0 Z15.0 F9000 ;move the platform down 15mm G92 E0 ;zero the extruded length G1 F200 E5 ;extrude 3mm of feed stock G92 E0 ;zero the extruded length again G1 F9000

[Xenomorphdelombre]

Ok, sorry for the spam. I kept G90 but changed M82 to M83 and also ticked the option "Relative Extrusion distances" in Simplify 3D. I created a XYZ Calibbration Cube GCODE. There is no other G92 other than the ones in my starting code. I'm about to try to print it... Let's hope I don't blow up my printer! :D
xyzCalibration_cube.gcode.txt

[Xenomorphdelombre]

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

[FormerLurker]

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.

[Core3dTech]

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

[Xenomorphdelombre]

The result: https://youtu.be/xo98SDQOdy0

[Billiam]

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.

https://gfycat.com/NimbleDeafeningDragon

[FormerLurker]

@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.

[Xenomorphdelombre]

@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

[Xenomorphdelombre]

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.

[FormerLurker]

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?

[SystemDisc]

Switching M82 to M83 and checking the box to use relative E coordinates in Simplify3D did the trick.
https://youtu.be/QaQtq5imQW8

[FormerLurker]

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!

[Boymeetsmill]

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

[FormerLurker]

@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!

[Boymeetsmill]

@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.

[FormerLurker]

@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)!

[Boymeetsmill]

@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

[FormerLurker]

Fantastic! If it worked, no logfile is necessary. Here's hoping the long print works as well!

[Pyro1989]

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)

[FormerLurker]

@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

[Pyro1989]

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.

[Boymeetsmill]

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

[FormerLurker]

@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.

[SystemDisc]

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.

[FormerLurker]

@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.

[SystemDisc]

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 😄

[Xenomorphdelombre]

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

[FormerLurker]

Thank you for that! Insert sigh of relief here...

[merlindk]

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

[FormerLurker]

@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?

[FormerLurker]

@merlindk, one more thing. Make sure you clear your browser cache after you load the new version. ctrl+F5 usually works for this.

[merlindk]

Ok, got it working on the guinnea pig branch. Starting a print now.

[merlindk]

it works!!! I love you!.

[FormerLurker]

@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!

[FormerLurker]

@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

[Core3dTech]

Looks like its working for me. I'll keep running additional tests. Thx!!!

[Shadowen]

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!

[FormerLurker]

Excellent @shadowen! I'll close it next time I'm near my PC, this app seems to have no option to do so.

[FormerLurker]

I dub this issue closed!

[SystemDisc]

@FormerLurker When will you be releasing a version of Octolapse that includes this fix? Octoprint still shows v0.3.1 in the plugin manager.

[FormerLurker]

@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.