Skip to content
This repository has been archived by the owner on Feb 8, 2024. It is now read-only.

M106 Ramp option defective. #111

Open
cwhinton opened this issue May 14, 2018 · 0 comments
Open

M106 Ramp option defective. #111

cwhinton opened this issue May 14, 2018 · 0 comments

Comments

@cwhinton
Copy link

This was done with 2.1.x RC7

When attempting to use the R option on M106 like M106 P3 R255, it throws the error:

05-14 17:28 root         ERROR    Error while executing M106: global name 'logging' is not defined
05-14 17:28 root         ERROR    Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/Redeem-0+untagged.1.pip10.g7351c6e.dirty-py2.7-linux-armv7l.egg/redeem/GCodeProcessor.py", line 121, in execute
    gcode.command.execute(gcode)
  File "/usr/local/lib/python2.7/dist-packages/Redeem-0+untagged.1.pip10.g7351c6e.dirty-py2.7-linux-armv7l.egg/redeem/gcodes/M106_M107.py", line 32, in execute
    fan.ramp_to(value, delay)
  File "/usr/local/lib/python2.7/dist-packages/Redeem-0+untagged.1.pip10.g7351c6e.dirty-py2.7-linux-armv7l.egg/redeem/Fan.py", line 49, in ramp_to
    logging.debug("Fan value: "+str(w))
NameError: global name 'logging' is not defined

After adding import logging following import logging, it doesn't error due to the missing global, but also doesn't actually enable the fan or respond 'OK' back to OctoPrint, causing OctoPrint to timeout and no other commands are then accepted by Redeem.

Recovery is to restart Redeem.

Workaround is to not use the ramp option.
goeland86 pushed a commit to goeland86/redeem that referenced this issue Jan 5, 2019
@ThatWileyGuy
Merged in debio/redeem/develop (pull request intelligent-agent#111)
145b34e 
Don't Hold on to Step Buffers After a Path is Complete

Paths in the path planner live in a circular buffer and store all
their steps in vectors. When we're done with a path, we zero it
and eventually it gets filled again. Originally, we were clearing
the vectors of steps with std::vector.clear(), which clear out all
the old steps but holds on to underlying buffer. Normally this is
an optimization, but it also means that every axis of every path
in the path queue (which is a few thousand elements long) will
always hold on to the largest buffer it's had to use so far.

This isn't a "leak" per se because we know where all that memory is
and no pointers have been "lost," but this does cause Redeem memory
usage to rise until it exceeds the maximum of the BBB, particularly
on prints with very long moves with many steps. To fix this, swap
the step vectors with empty vectors to force std::vector to free
these underlying buffers and re-allocate whenever a Path is used.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@cwhinton