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

latest dev not displaying set temp. #360

Closed
cakeller98 opened this issue Jan 24, 2014 · 32 comments

Comments

Projects
None yet
4 participants
@cakeller98
Copy link

commented Jan 24, 2014

temp is set but always showing off.

image

@cakeller98

This comment has been minimized.

Copy link
Author

commented Feb 11, 2014

Perhaps I was unclear... Target T and Target Bed always read "Off" no matter what I try to set. In addition if I type a temp into the box, also - sets the temp, but always reverts to reading "off"

@foosel

This comment has been minimized.

Copy link
Owner

commented Feb 15, 2014

How recent is latest? There was a bug fixed in 7231acc that caused this behaviour. Current devel should not show this behaviour:

image

@cakeller98

This comment has been minimized.

Copy link
Author

commented Feb 15, 2014

My server is currently using commit 858873d which is the one immediately following the one you say fixed it.

For the last few weeks it has been the latest commit that was not a "WIP" - I will update to the latest devel commit and test.

@cakeller98

This comment has been minimized.

Copy link
Author

commented Feb 15, 2014

Tested commit 592f3dc and still shows the same: "off"

This is on windows 8.1.
The non display of temp is on Google Chrome web browser, on Windows 7 x64.
Also tested the Web UI in IE, and still no luck.

Also - if I type a temp into the box and press enter, nothing changes. I set the temp using the dropdown box, to 230 C, then typed in 100 into the box, pressed enter, temp kept climbing... (180 deg C)

Anyway - the only thing I haven't done is go through the files in the scripts folder and try removing all of them and then recompiling....... should I do that?

@foosel

This comment has been minimized.

Copy link
Owner

commented Feb 15, 2014

This is a long shot, but could you try cleaning your browser's cache?

@cakeller98

This comment has been minimized.

Copy link
Author

commented Feb 15, 2014

Tried in IE and Chrome... cleared the cache, still same behavior.

I just deleted everything from the scripts and lib folders that had a modification date same as "now" - so deleted everything eggy that was built since updating to the latest commit, and then ran the python setup.py install.

still same results.

is there a command line switch for octoprint that would allow to confirm the commit? or something? would be a nice feature... since it's compiled it's challenging, without rebuilding, to know that everything is updated to the latest revision.

FWIW - the set-point graph isn't being drawn either. Only the "current temp"

so... not sure why that'd be, but wouldn't be far fetched if it was related?

@cakeller98

This comment has been minimized.

Copy link
Author

commented Feb 15, 2014

Here is a link to a video showing the behavior - hope this helps explain what is going wrong.

https://www.dropbox.com/s/kf343km3whk7nvm/oxtoprint.mov

you can skip the first 30 seconds or so... sorry.

@foosel

This comment has been minimized.

Copy link
Owner

commented Feb 15, 2014

Taking a look into your terminal tab, how do the temperature replies from your printer look like?

@cakeller98

This comment has been minimized.

Copy link
Author

commented Feb 15, 2014

Hmmm will take a look...

On Saturday, February 15, 2014, Gina Häußge notifications@github.com
wrote:

Taking a look into your terminal tab, how do the temperature replies from
your printer look like?

Reply to this email directly or view it on GitHubhttps://github.com//issues/360#issuecomment-35170435
.

--- Chris

@emccarron

This comment has been minimized.

Copy link

commented Feb 17, 2014

Think I'm seeing the same thing.

Temp comes back as:

Recv: ok 454107
Recv: T:2.02 B:2.33 @:0
Recv: wait

(The heat was off in the office...)

But I'm not sure that's the problem -- it's the "target" field that's not displaying the chosen temperature. Everything else still works, it just remains at "OFF" displayed in the target field, regardless of whether it's set via the UI or from gcode.

I'm running :
Branch: devel, Commit: 858873d

@foosel

This comment has been minimized.

Copy link
Owner

commented Feb 17, 2014

What firmware and printer is that?

It's not reporting the target temperature back, will have to build around
that.

@cakeller98

This comment has been minimized.

Copy link
Author

commented Feb 17, 2014

m using repetier, and an azteeg x3 on a delta style printer.

@emccarron

This comment has been minimized.

Copy link

commented Feb 17, 2014

Repetier here too. Homebrew Rostock.

I'll look at the FW and see if there's a "Report target temp" option I have commented out or something... What should the reply look like?

@foosel

This comment has been minimized.

Copy link
Owner

commented Feb 17, 2014

Hm, looks like I misremembered things in repetier, because I was pretty
sure it reported target temps back just like marlin (eg "T:21.8/206.0"),
but looking at the code again it doesn't. Which is a shame btw, since this
way there will be no way to determine the target temperature when printing
from SD card.

With multi extruder support I changed the temperature parsing and
overlooked that. Will have to fix by testing if a target temperature is
being returned and if not use the last set one. Currently sick so might
take a bit.

@emccarron

This comment has been minimized.

Copy link

commented Feb 17, 2014

No hurry -- it still works like a champ as is. :)

Thanks for your work!

@cakeller98

This comment has been minimized.

Copy link
Author

commented Feb 17, 2014

Perhaps we should ask repetier to adjust the temp reporting to match the way marlin does. But regardless - Octoprint should be tolerant, as you @foosel said it would be.

@cakeller98

This comment has been minimized.

Copy link
Author

commented Feb 18, 2014

Ahhh....
Send: N6 M190 S80_86
Recv: TargetBed:80
Send: N19 M109 S225_85
Recv: TargetExtr0:225

I guess that makes sense then... if SD Cards do the same (report the temps set)

I don't use SD card, so... I am only guessing.

@cakeller98

This comment has been minimized.

Copy link
Author

commented Feb 18, 2014

BTW - hope you feel better soon :)

@emccarron

This comment has been minimized.

Copy link

commented Feb 27, 2014

I've lost track of where master is in relation to dev, but

Branch: master, Commit: 0747336

Shows temps properly below the graph.

image

@cakeller98

This comment has been minimized.

Copy link
Author

commented Feb 28, 2014

Repetier claims to have made the temp reporting match what marlin does. I will update the printer's firmware and test.

However for those that don't have the latest firmware, I would suggest that it would be a good fall-back to set the set temp from whenever you change it in the UI anyway... Also, I provided the format Repetier firmware reports temp changes as well above... but here it is again:

Send: N6 M190 S80*86
Recv: TargetBed:80
Send: N19 M109 S225*85
Recv: TargetExtr0:225

hope this all helps. I have a single extruder, so I assume TargetExtr0 - TargetExtr5 are all available, as Repetier firmware claims to support up to 6 extruders.

in conclusion - I am suggesting that the target temps be set in all of the 3 possible places, and not be set to zero if one of those places happens to not report the info.

  1. best is as you wanted it - by the M105 gcode should report back temp/target.
  2. next best (at least for repetier firmware) use the Recv: TargetBed and Recv: TargetExtr# whenever received
  3. any time you set the temp manually from Octoprint the target temp should be set...unless there is concern that OP thinks it set the temp, but firmware somehow is unaware...

perhaps for situation 1 - IF by the M105 there is no included target temp, then perhaps set a flag which says that the firmware the user is using does not support on-the-fly target temp reporting, put a little red ! next to the target temp, and below the window or somewhere, have a warning message that says something to the effect of "! FYI, your version of your firmware does not report the target temp"

Thanks :)

EDIT: Confirmed the latest Repetier firmware does, in fact, report the target temps. At least for single extruders it works correctly now! 💃 Still suggesting the above would be good to implement.

foosel added a commit that referenced this issue Mar 3, 2014

Changed handling of bed temperatures
Will now be left unset if not detected (instead of dying a horrible death), modified frontend to not display bed settings in such cases. While at it also (hopefully) fixed "Target: off" for bed issue.

TODO: Support repetier's "TargetBed:", "TargetExtr%n" syntax

Fixes #399, partially solves #360

foosel added a commit that referenced this issue Mar 3, 2014

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 3, 2014

I've added this in the current devel branch. Tests would be welcome, I only simulated it on the virtual printer. After updating you'll need to activate support for the format via the settings and then reconnect:

image

@nullie

This comment has been minimized.

Copy link
Contributor

commented Mar 5, 2014

At 27322a9 target bed temperature seems to work, but extruder still doesn't.

2014-03-05 03:10:48,179 - SERIAL - DEBUG - Send: M104 S232.000000
2014-03-05 03:10:48,190 - SERIAL - DEBUG - Recv: ok 0
2014-03-05 03:10:48,199 - SERIAL - DEBUG - Recv: TargetExtr0:232
2014-03-05 03:10:53,688 - SERIAL - DEBUG - Send: M140 S83.000000
2014-03-05 03:10:53,700 - SERIAL - DEBUG - Recv: ok 0
2014-03-05 03:10:53,715 - SERIAL - DEBUG - Recv: TargetBed:83
@nullie

This comment has been minimized.

Copy link
Contributor

commented Mar 5, 2014

I feel like I should switch to marlin to solve many issues at once

@emccarron

This comment has been minimized.

Copy link

commented Mar 7, 2014

What he said.

Bed temperature on the temp tab works great now.

Extruder 0, not so much.

It's getting spit out of repetier just like it shows above.

Branch: devel, Commit: f3ee2d2

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 10, 2014

Hm... I just adjusted the virtual printer to fully support this style of temperature reporting, just to make sure, and I can't reproduce that problem, extruder target temp is detected fine here on my end. Any ideas what I'm missing here?

Send: M105
Recv: ok B:1.00 T0:0.00 T1:0.00 T2:0.00 T3:0.00 @:64
Send: M104 T0 S180.000000
Recv: ok
Recv: TargetExtr0:180
Recv: wait
Send: M105
Recv: ok B:1.00 T0:1.02 T1:0.00 T2:0.00 T3:0.00 @:64
Send: M104 T1 S210.000000
Recv: ok
Recv: TargetExtr1:210
Send: M105
Recv: ok B:1.00 T0:11.08 T1:1.02 T2:0.00 T3:0.00 @:64
Send: M140 S60.000000
Recv: ok
Recv: TargetBed:60
Send: M105
Recv: ok B:3.03 T0:33.12 T1:23.06 T2:0.00 T3:0.00 @:64
Send: M105
Recv: ok B:23.05 T0:53.14 T1:43.08 T2:0.00 T3:0.00 @:64
Send: M105
Recv: ok B:43.10 T0:73.19 T1:63.13 T2:0.00 T3:0.00 @:64

image

I also took a look at the firmware source, but couldn't spot anything in the output differing from the above either. The only idea I have right now that something is preceeding the TargetExtr string in the output from the firmware, causing the regex in OctoPrint not to match, but I couldn't spot anything like that.

@cakeller98

This comment has been minimized.

Copy link
Author

commented Mar 10, 2014

Would it hurt to swallow up to the "arget" such that no matter what precedes it, it would have no issue? Obviously if it's a different issue that won't fix it, but it wouldn't hurt, would it?

@nullie

This comment has been minimized.

Copy link
Contributor

commented Mar 10, 2014

Extruder target temperature gets reset here: https://github.com/foosel/OctoPrint/blob/devel/src/octoprint/util/comm.py#L572

Repetier report string doesn't contain target temperatures

@nullie

This comment has been minimized.

Copy link
Contributor

commented Mar 10, 2014

I should notice, that target extruder actually "blimps" when you press set button.

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 10, 2014

It only get's reset there in case of only a single extruder being present
though. We are talking a multi extruder setup here, or am I mistaken?
Still, nicely spotted, this has to look different.

On Mon, Mar 10, 2014 at 2:35 PM, Ilya Novoselov notifications@github.comwrote:

I should notice, that target extruder actually "blimp" when you press set
button.

Reply to this email directly or view it on GitHubhttps://github.com//issues/360#issuecomment-37182162
.

@nullie

This comment has been minimized.

Copy link
Contributor

commented Mar 10, 2014

All screenshots except your show only one extruder :)

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 10, 2014

I pushed a fix to the line above, referenced this issue, but for whatever reason it doesn't show up here.. in any case see 29be139, pull, test and report back please :)

And sorry for the multi extruder mixup then, I was looking into another issue just now that was multi only, and I managed to mix those two tickets up.

@nullie

This comment has been minimized.

Copy link
Contributor

commented Mar 10, 2014

Yeah, works now. Thanks.

@foosel foosel closed this Mar 10, 2014

Salandora pushed a commit to Salandora/OctoPrint that referenced this issue Mar 11, 2014

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.