Stabilization Error When Taking Snapshot

[JasonLamey]

If this is a feature request describe it here

___REPLACE_THIS__FEATURE_REQUEST_DESCRIPTION_GOES_HERE

Version of Octolapse

Octolapse Version: 0.4.0

Version of OctoPrint

OctoPrint Version: 1.4.0

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

1. Upload gcode file to Octoprint server.
2. Select file from file browser in Octoprint.
3. Select Octolapse tab.
4. Ensure Testing is active.
5. Run print until the first snapshot should occur.

What should have happened?

Print head should travel to stabilization location (back-left), snapshot should be taken.

What happened instead?

Print head does not go to stabilization location (back-left), and stabilization error occurs.
Print continues.

Operating System running OctoPrint and Octolapse

OS Name: Mac OS
Os Version: 10.13.6 (High Sierra)

Printer model & used firmware incl. version

Printer Model: Creality CR-10
Printer Firmware Version: v1.0 (stock firmware)

Browser and version of browser, operating system running browser

Browser: Brave v1.3.115
Browser OS: Mac OS 10.13.6 and Windows 10

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

Link to Gcode File: https://gist.github.com/JasonLamey/93a3eef31536a042e139a8c2af020ea3

Link to settings.json

Link to settings.json with all passwords removed: https://gist.github.com/JasonLamey/9f13beded76938be3f78ec95f01a7f03

Link to plugin_octolapse.log

Link to plugin_octolapse.log: https://gist.github.com/JasonLamey/9cbf5a99c2f1b2390efed47a7c594cb0

Link to octoprint.log

Link to octoprint.log: https://gist.github.com/JasonLamey/27e1ffa36a2e63a3aee62271a5f25ae2

Link to contents of Javascript console in the browser

Link to javascript console output: https://pastebin.com/xBYaxrdy

Screenshots and/or videos of the problem:

Screenshot/Video Links: ___REPLACE_THIS__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]

I'll try running your gcode through the debugger using your settings. Unfortunately there is nothing in the log relating to the stabilization error. It could be an issue running Octolapse on a Mac relating to older non c++ 11 compliant compilers, but I don't have access to a mac for testing :( Still, I'll see if I can find anything out.

[JasonLamey]

Thanks, @FormerLurker . I've been beating my head against this for a week, and I've not had any luck, so far.

[Gerporgl]

It seems to be the same error I am getting and just logged an issue as well: #579
You have more stuff enabled in your logs, so it is easy to get lost, but I can see the following logs which looks similar to what I get:

2020-07-09 14:07:12,703 - octolapse.timelapse - INFO - About to take a snapshot.  Triggering Command: G1 X137.082 Y155.273 E32.81587
2020-07-09 14:07:12,704 - octolapse.timelapse - ERROR - Failed to take a snapshot for the provided snapshot plan.
Traceback (most recent call last):
  File "/Users/jlamey/OctoPrint/venv/lib/python3.8/site-packages/octoprint_octolapse/timelapse.py", line 407, in _take_timelapse_snapshot_precalculated
    snapshot_gcode = self._gcode.create_gcode_for_snapshot_plan(
  File "/Users/jlamey/OctoPrint/venv/lib/python3.8/site-packages/octoprint_octolapse/stabilization_gcode.py", line 1106, in create_gcode_for_snapshot_plan
    if not self.initialize_for_snapshot_plan_processing(
  File "/Users/jlamey/OctoPrint/venv/lib/python3.8/site-packages/octoprint_octolapse/stabilization_gcode.py", line 363, in initialize_for_snapshot_plan_processing
    self.distance_to_lift = snapshot_plan.initial_position.distance_to_zlift(self.z_lift_height)
  File "/Users/jlamey/OctoPrint/venv/lib/python3.8/site-packages/octoprint_octolapse/gcode_processor.py", line 515, in distance_to_zlift
    if amount_to_lift < utility.FLOAT_MATH_EQUALITY_RANGE:
TypeError: '<' not supported between instances of 'NoneType' and 'float'
2020-07-09 14:07:12,705 - octolapse.timelapse - INFO - The snapshot has completed

and on my side I see this error:

2020-08-16 02:51:33,067 - octolapse.timelapse - ERROR - Failed to take a snapshot for the provided snapshot plan.
Traceback (most recent call last):
  File "/home/octoprint/OctoPrint/venv/lib/python3.8/site-packages/octoprint_octolapse/timelapse.py", line 407, in _take_timelapse_snapshot_precalculated
    snapshot_gcode = self._gcode.create_gcode_for_snapshot_plan(
  File "/home/octoprint/OctoPrint/venv/lib/python3.8/site-packages/octoprint_octolapse/stabilization_gcode.py", line 1106, in create_gcode_for_snapshot_plan
    if not self.initialize_for_snapshot_plan_processing(
  File "/home/octoprint/OctoPrint/venv/lib/python3.8/site-packages/octoprint_octolapse/stabilization_gcode.py", line 363, in initialize_for_snapshot_plan_processing
    self.distance_to_lift = snapshot_plan.initial_position.distance_to_zlift(self.z_lift_height)
  File "/home/octoprint/OctoPrint/venv/lib/python3.8/site-packages/octoprint_octolapse/gcode_processor.py", line 515, in distance_to_zlift
    if amount_to_lift < utility.FLOAT_MATH_EQUALITY_RANGE:
TypeError: '<' not supported between instances of 'NoneType' and 'float'

Maybe an issue related to python 3.8?

[Gerporgl]

I did a quick test with conditional operators on python2 with a NoneType and a float and it does not throw any error, however on python3 (3.8...) it does throw an exception like what we are seeing in our logs.

Looking very quickly at the code, it seems to rely on assigning None to a variable in a couple of cases and then do some comparison after that with a float.

However Octoprint is supposed to be compatible with Python 3 so maybe the problem is triggered by something else, I don't know.

[FormerLurker]

@Gerporgl,

What OS is Octoprint running on for you?

[Gerporgl]

@FormerLurker My OS is essentially Ubuntu 20.04, but using the Armbian distro (as mentioned in #579) for an Odroid C2.

[FormerLurker]

@Gerporgl, My guess is this is compiler related. I have experienced this myself on a few OSs. Rasbian and Windows seem to work just fine, but some linux flavors and MacOs don't seem to work properly. It seems that the C++ extension is returning null values within the snapshot plan, which should not happen. Unfortunately this might take a while to debug. If I had a mac to test on I think I could kill two birds with one stone here. The ArcWelder plugin has a similar problem, and I believe it's probably caused by improper linking due to my poor knowledge of cross platform c++ development :( Hopefully I can learn what's going on and how to prevent it in all cases.

[Gerporgl]

Thanks for the info. I tried to hack a fix myself to pass this single error, but realised there was more to this issue when I saw my printer going in the corner of the bed and going up and up... then I turned it off. I'll keep monitoring this thread to see if there is any new development.

You could also install Ubuntu 20.04 in a normal PC also (even from a removable USB), if you can't get a Mac computer, I think you may get the same behaviour as Armbian Focal.

[Rippernz]

I am also getting this error.
I have a Pi 4 8GB running Raspberry OS
OctoPrint 1.4.2 Python 3.7.3 OctoPi 0.18.0

I recently updated Python to v3 but i cant recall if it was giving errors before that.

the below is my error from the octolapse log.

`2020-10-05 02:04:51,703 - octolapse.timelapse - ERROR - Failed to take a snapshot for the provided snapshot plan.
Traceback (most recent call last):
  
File "/home/pi/oprint/lib/python3.7/site-packages/octoprint_octolapse/timelapse.py", line 409, in _take_timelapse_snapshot_precalculated self._trigger_profile.get_snapshot_plan_options()
  
File "/home/pi/oprint/lib/python3.7/site-packages/octoprint_octolapse/stabilization_gcode.py", line 1107, in create_gcode_for_snapshot_plan snapshot_plan, g90_influences_extruder, options
  
File "/home/pi/oprint/lib/python3.7/site-packages/octoprint_octolapse/stabilization_gcode.py", line 363, in initialize_for_snapshot_plan_processing self.distance_to_lift = snapshot_plan.initial_position.distance_to_zlift(self.z_lift_height)

File "/home/pi/oprint/lib/python3.7/site-packages/octoprint_octolapse/gcode_processor.py", line 515, in distance_to_zlift if amount_to_lift < utility.FLOAT_MATH_EQUALITY_RANGE: 

TypeError: '<' not supported between instances of 'NoneType' and 'float'`

let me know if you need anything else from me.

[Prutsium]

Same thing here ....
Attached the log files
octoprint(2).log
plugin_octolapse.log

Octoprint version: Version 1.4.2
Octopi version: Version 0.18.0, running on Raspberry Pi 4 Model B Rev 1.2
Running on Octopi os version: Octolapse (0.4.0)
Using pip of "/home/pi/oprint/bin/python3", Version 20.2.4
Installation directory: /home/pi/oprint/lib/python3.7/site-packages ("--user" flag: no)

[Prutsium]

I Tried as suggested the Classic Stabilisation but run into a Error about G21.
No clue how to get this into my slicer (Prusa Slicer)

I Noticed #624 and will check the Gcodeprocessor.

[tech2077]

I took a look at where weird value were being introduced, and it appears that it's likely an issue of boolean conversion to long ints. Bools basically have absolutely no guaranteed values when optimized, so they're extremely unsafe and non-portable to deal with. The offending piece of code here seems to be in position.cpp and extruder.cpp, with several bools being cast to long ints and ending up with effectively random values. The checks in python are for 0 false/1 true, so this breaks down when it's optimized.

I put the fix on my fork, I can do a PR if it seems good enough.

[FormerLurker]

@tech2077, oh man, i can't wait to check it out!! Will do right after work, thank you so much!!!

[FormerLurker]

@tech2077, I had some free time while some ISP issues were being resolved, and integrated your code. The c++ code is actually contained in a separate project, which updates the Octolapse source on demand, so a PR is not the best way to deal with this (I need to move the c++ code to github...). However, I did add your name to the about page of the plugin for submitting this fix:

You and @JasonLamey can try installing from the plugin manager using this link in the From Url... box: https://github.com/FormerLurker/Octolapse/archive/88aa71f0fbac306b0d9acf19dff7388a30b29b64.zip

If it works I'll try to promote this to master over the weekend.

Regarding the c++, I'm SO glad to have learned this. python c++ libs have no concept of a bool, and that code works fine in so many cases, so I was surprised to learn about the conversion issues with optimized code. I don't really know any c++ devs, and this was my first cross platform project, so there are bound to be tons of noob mistakes in there. Open-Source for the win :)

[FormerLurker]

@tech2077, initial reports suggest you have solved this seemingly intractable issue. If you have a PayPal account, i would be glad to send a tip. You have no idea how muct time I wasted on this issue. You are a hero!

[tech2077]

Yeah, cross-platform C++ is a pain to deal with, especially with optimizations and other language ffi's. No need for a tip, I just found this plugin last night and it's working amazingly today with the fix, that's reward enough :)

[Kambius]

Guys, thank you so much! I'm working on my master's thesis that will detect print failures. It uses Octolapse so I was really frustrated by this bug, but this fix solved it!

[FormerLurker]

@Kambius, that is great! If your project is open source, post a link! I would love to see it.

[Kambius]

It is currently in the early stages of development, but if I achieve good results, I will definitely share it with everyone :)
@FormerLurker thank you for your great work!

[molepage]

@Kambius that's interesting, so it would be an alternative to The Spaghetti Detective?

[Kambius]

@molepage yes, but there is a lot of work to be done ;)

[FormerLurker]

This should be fixed in V0.4.1, which just dropped. Might take a while to show up in the plugin manager. Reopen a new issue if you continue to have problems. Thanks!