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 notifications@github.com 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 notifications@github.com 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 notifications@github.com 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 notifications@github.com 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