Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

M105 timer can cause an M105 cascade on long command-ok-cycles #1275

Closed
foosel opened this issue Mar 11, 2016 · 1 comment

Comments

Projects
None yet
1 participant
@foosel
Copy link
Owner

commented Mar 11, 2016

Problem

If the user has configured a long comm timeout (> 5s) or a long running command, the M105 polling timer will enqueue multiple M105 commands that then will cascade through comms once the timeout gets resolved/the long running command ends.

The problem is that the polling timer doesn't write into the send queue (which is typed) but into the command queue which then in turn gets written into the send queue, but isn't typed itself.

Solution

Make the command queue a typed queue as well.

@foosel foosel self-assigned this Mar 11, 2016

@foosel foosel added this to the 1.2.10 milestone Mar 11, 2016

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Mar 11, 2016

For testing:

  • Make sure M800 is not configured as a long running command

  • Connect to virtual printer

  • Upload a file with the contents

    M117 M105 cascade test start
    M800
    M117 M105 cascade test end
    
  • Send !!DEBUG:sleep_after_next M800 30 to printer

  • Print file

Should log several times in octoprint.log that the temperature type was already in the command queue, will only send one additional M105 if a timeout is encountered.

@foosel foosel closed this in baab1ce Mar 16, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.