No extrusion after first snapshot: "Too long extrusion prevented"

diaconesq commented 3 years ago

If this is a feature request describe it here

_REPLACE_THISFEATURE_REQUEST_DESCRIPTION_GOES_HERE

Version of Octolapse

Octolapse Version: 0.4.1 but happened with earlier versions too

Version of OctoPrint

OctoPrint Version: 0.5.1 but happened in earlier versions too

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

Enabled Octolapse plugin
Sliced model in Cura and sent to OctoPrint (Cura snippet for exporting the settings already added)
Started printing via OctoPrint

What should have happened?

The model should print (and it does, when OctoLapse is disabled)

What happened instead?

The first layer and a bit of the 2nd got printed, then the printer would keep going, but not extrude any filament (printing in the air). I tried several times, the extrusion stops at exactly the same spot. It doesn't look like physical jamming - no grinding in the extruder, it just doesn't extrude at all.

!! Looked at the Octoprint 'real-time Gcode' tab (don't know the actual name) and there are a bunch of messages like: Send: N596 G1 F2100 X102.402 Y131.791 E658.96266*2 Recv: echo: too long extrusion prevented

Maybe Octolapse sets the extrusion mode to 'relative' when taking a picture and does not reset it to 'absolute' afterwards ? I included the plugin_octolapse.log, it's fairly short - I cancelled the print after then issue repro'd.

Actually: Is there a way to download the actual gcode sent to the printer, including OctoLapse's modifications?

Operating System running OctoPrint and Octolapse

OS Name: OctoPi Os Version: 0.17.0

Printer model & used firmware incl. version

Printer Model: Creality Ender 3 Printer Firmware Version: Marlin 1.x with custom build, but it was working fine with Octolapse in the past.

Browser and version of browser, operating system running browser

Browser: _REPLACE_THISBROWSER_VERSION_GOES_HERE Browser OS: _REPLACE_THISBROWSER_OS_GOES_HERE

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: https://imgur.com/a/t7p8GmD

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.

diaconesq commented 3 years ago

Another bit of info to narrow it down. I tried printing again, this time watching it closely. Extrusion stops EXACTLY after the 1st snapshot is taken, further strengthening my suspicion that Octo lapse changes extrusion mode to 'relative'

FormerLurker commented 3 years ago

Yeah, i suspect there is some printer setting that is incorrect, but I haven't been able to look yet. My guess would be the g90/G91 influences extruder setting. Will double check asap.

FormerLurker commented 3 years ago

What do you have for this settings:

FormerLurker commented 3 years ago

Looks like my suspicion was correct. I tested out your gcode, and due to the way your start gcode is configured, having the G90/G91 setting incorrect will cause your e axis to be flipped.

The easiest way to fix this is to use the ender 3 profile from the profile repository like this:

I see you've been using Octolapse for a long time :) The settings upgrade was difficult, and you have a bunch of the old printer profiles. I considered not supporting the old printer profiles, but got a lot of pushback during testing. I recommend you just delete all of those and start using the make/model drop down if your printer is in there. You'll notice these firmware settings:

I override the OctoPrint settings in all the new profiles just in case. I suspect your g90/g91 influences extruder setting is wrong in OctoPrint, so you should fix that.

diaconesq commented 3 years ago

The G90/91 setting is "enabled" in my OctoPrint. I'll test your suggestions today, hopefully in the next 30 mins. Thanks!

FormerLurker commented 3 years ago

The G90/91 setting is "enabled" in my OctoPrint.

Bingo! This is an insane thing to get right. There is no good way to test for it without unloading filament and starting at the gear (though some printers properly report E via M114, but others do not). I really wish this weren't a thing, because it causes tons of problems. It's easy for the slicers to get right (just always add M82/M83 after G90/G91), but if you are reading gcode it can be ambiguous. One printer MFG was going to switch this behavior in a regular firmware update, and luckily I was able to convince them not to. It would have caused havoc for my plugin (now there are 2 valid settings for a single printer with stock firmware), and broken all sorts of gcode. I don't think they think about these problems from any other perspective than slicer to printer, but I guess that shouldn't really be surprising.

Anyway, be sure you alter that OctoPrint setting 2. In general, that is only true for smoothieware and marlin 2, though there are exceptions.

diaconesq commented 3 years ago

Fixed!! Thank you, I had basically given up on OctoLapse for some months now due to this issue. So glad I decided to give it another go! I had cancelled my Patreon subscription recently "'cause I ain't using it any more". I'll turn it back on today, you really deserve the support!

"I know I know nothing", but...: Regarding getting the G90/91 behaviour right - would it work to have a heuristic for it that looks at the whole gcode file? If the E values generally keep increasing (except for retractions), then it's probably absolute E. If they are always small numbers, it's relative E.

FormerLurker commented 3 years ago

"I know I know nothing", but...: Regarding getting the G90/91 behaviour right - would it work to have a heuristic for it that looks at the whole gcode file?

It is possible, but with custom layer and filament change gcode floating around, most of which operates in relative mode (it has to unless the slicer provides some token replacement with some advanced calculation capability), this would 'fix' the problem for some and break it for others. Also, when running from Octoprint, other plugins can inject gcode into the stream, changing things on the fly.

Octolapse will always get the axis mode correct provided the following two conditions are met:

The 'default' mode is correct OR an explicit G90/G91 and/or M82/M83 command(s) appear in the start gcode (they ALWAYS should).
The G90/G91 influences extruder setting is correct.

For 1 it is insane how often I see start/end gcode without a G90/G91 or M82/M83 at all. I see so many issues about 'random crashes' that are really caused by this, but it's hard to track down since a printer reset will fix it. This is simply a config issue.

For 2, the easiest way is to just use one of the pre-configured profiles. I've written a firmware checker for my other plugin, Arc Welder, which is still in development, but it uses a lookup based on several firmware queries, and can (at least in some cases) alert you if the G90/G91 setting is wrong.

You could also fix this in your start gcode by adding the appropriate M command (82/83) after each G90/G91.

FormerLurker commented 3 years ago

I had cancelled my Patreon subscription recently "'cause I ain't using it any more". I'll turn it back on today, you really deserve the support!

Thank you so much! I recently had to buy a bunch of equipment (2xPi 4, mem cards, PSUs, HD Cam), so I'm glad this will be offset somewhat. It does really help.

FormerLurker / Octolapse