[Bug] Printer profiles that don't have a Heated Bed should never send bed temperatures or setpoints

[pyjamasam]

1. What were you doing?
   • Looking at the temperature tab
2. What did you expect to happen?
   • There should be no bed related information or UI elements displayed as the active printer doesn't have a heated bed configured.
3. What happened instead?
   • Bed related information was displayed and a bogus temperature was displayed
4. Branch & Commit or Version of OctoPrint:
   • 1.2.7 (master branch)
5. Printer model & used firmware incl. version
   (if applicable - always include if unsure):
   • Kossel mini delta, running on an azteeg x5 using smothieware edge
6. Browser and Version of Browser, Operating
   System running Browser (if applicable - always
   include if unsure):
   • OS X 10.11.1, Chrome Version 47.0.2526.73 beta (64-bit)
7. Link to octoprint.log on gist.github.com or pastebin.com
   (ALWAYS INCLUDE AND DO NOT TRUNCATE):
   • Can be provided if required, but at this point I don't think they have any detail that's useful.
8. Link to contents of terminal tab or serial.log on
   gist.github.com or pastebin.com (if applicable - always
   include if unsure or reporting communication issues AND
   DO NOT TRUNCATE):
   • Can be provided if required, but at this point I don't think they have any detail that's useful.
9. Link to contents of Javascript console in the browser
   on gist.github.com or pastebin.com or alternatively a
   screenshot (if applicable - always include if unsure
   or reporting UI issues):
   • Can be provided if required, but at this point I don't think they have any detail that's useful.
10. Screenshot(s) showing the problem (if applicable - always
    include if unsure or reporting UI issues):
    • https://www.dropbox.com/s/a0aetwflqibyqb7/Screen%20Shot%202015-11-28%20at%2021.34.20.png?dl=0

I have read the FAQ.

----- Further information and description -----
When a printer profile is setup and doesn't have a heated bed there should never be any data sent to the client pertaining to the bed.

I run smothieware, and in the process of calibrating my delta I guess octoprint found something in the serial stream that it thought was a temperature line that had a bed temperature in it.

Marlin exposes this problem much more since its standard response to a M105 includes a bed temperature all the time (even if it's 0)

After that point whenever I load the UI there is a bed temperature displayed (as well as a control to set the bed temperature - which won't actually work because I don't really have a bed).

If I disconnect and reconnect to the printer then the bed ui related components no longer appear (until the serial stream parser finds something that it things is a bed temperature again)

I understand that fixing this issue really just masks the mistake the parser is making in finding the bed temperature, but that parsing code is already making a large number of assumptions and I think it would just be easier to clean up the display and UI code.

While I realize that this isn't really a show stopper, I just find it to be something of a polish point.

Though I would pop an issue for it.

If you need any more info I'd be glad to provide what I can.

chris.

[GitIssueBot]

Hi @pyjamasam,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Please take a look at the Contribution Guidelines and the page How to file a bug report on the project wiki, which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug, please take special note of the title format to use as described in the Contribution Guidelines.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2015-12-13 02:20) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

[foosel]

Should be solved in devel and maintenance (and hence will be part of 1.2.8 release).

If currently selected printer profile doesn't have a heated bed, not only will no UI elements for bed related stuff be displayed (including the temperature curve), the REST API will also return a 409 if clients attempt to send bed commands, the printer state resource will have the bed temperature data stripped, no bed temperature will be reset to 0 on cancel and M112 and also the comm layer in general will refuse to send M140 or M190 and instead log a warning to the terminal/serial.log why it's not sending those commands.

[voglster]

As a note, for people upgrading dev as it comes out. My heated bed disappeared when this patch was pushed. For anyone who runs into this just go to your printer profile and checkoff heated bed.

Before you do your next release foosel you might want to comment on this or turn on the heated bed by default so behavior doesn't change.

[foosel]

It will be mentioned in the release notes as always. In fact, it is already part of the change log on the maintenance branch. Might add an additional heads up. But I guess people will still stumble over that anyhow, considering the bad track record of people reading documentation I provide ;)

Making heated beds across all printer profiles a default however is imho the wrong approach, that would mask a configuration error on the user's part and might lead to larger problems in the future.