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

[RC Feedback] Feedback on the 1.3.6rc2 Release Candidate #2269

Closed
foosel opened this Issue Dec 5, 2017 · 21 comments

Comments

7 participants
@foosel
Owner

foosel commented Dec 5, 2017

Please provide general feedback on your experience with the 1.3.6rc2 Release Candidate here. An "All is working fine" is valuable feedback as well, because it tells me that people in fact are testing the RC and just not finding any problems. Thanks :)

If you run into any obvious bugs, please open a new ticket and follow "How to file a bug report".

Note for people who already ran 1.3.6rc1, then downgraded back to 1.3.5

You'll need to do a tiny fix in your config.yaml, made necessary by the switch to pip as update method in 1.3.6rc1, or you won't be able to switch back again to Maintenance RCs to test this second RC. You'll need to remove the method: pip line under plugins.softwareupdate.checks.octoprint and then restart.

You can easily do this config.yaml change via the YamlPatcher plugin using the patch string

[["remove", "plugins.softwareupdate.checks.octoprint.method", ""]]

or via the command line using

sed -i -e "s/method: pip//g" ~/.octoprint/config.yaml
@b-morgan

This comment has been minimized.

Show comment
Hide comment
@b-morgan

b-morgan Dec 5, 2017

I'm not seeing any printing problems but I don't think the issue(s) with the Gcode Viewer are fixed yet. I'll capture some data after the current print finishes.

b-morgan commented Dec 5, 2017

I'm not seeing any printing problems but I don't think the issue(s) with the Gcode Viewer are fixed yet. I'll capture some data after the current print finishes.

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Dec 5, 2017

Owner

@b-morgan which issue are you talking about? #2267?

Owner

foosel commented Dec 5, 2017

@b-morgan which issue are you talking about? #2267?

@b-morgan

This comment has been minimized.

Show comment
Hide comment
@b-morgan

b-morgan Dec 5, 2017

Not exactly. I started a print, the GCode Viewer was working (with Sync with job progress checked). I left to do other things and when I came back, the GCode Viewer screen was blank (print was still running).

It is a short print so I'm going to reboot everything, enable safe mode, print it again, and be more observant. Then I should have enough information to open another issue.

b-morgan commented Dec 5, 2017

Not exactly. I started a print, the GCode Viewer was working (with Sync with job progress checked). I left to do other things and when I came back, the GCode Viewer screen was blank (print was still running).

It is a short print so I'm going to reboot everything, enable safe mode, print it again, and be more observant. Then I should have enough information to open another issue.

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Dec 5, 2017

Owner

That's an issue that I can't remember seeing a ticket for?

Is this something that only started under 1.3.6* or was that something you also saw before? If the latter it is not a regression and will have to wait until 1.3.7 now.

Owner

foosel commented Dec 5, 2017

That's an issue that I can't remember seeing a ticket for?

Is this something that only started under 1.3.6* or was that something you also saw before? If the latter it is not a regression and will have to wait until 1.3.7 now.

@b-morgan

This comment has been minimized.

Show comment
Hide comment
@b-morgan

b-morgan Dec 5, 2017

I haven't seen any GCode Viewer issues with 1.3.5 so I believe this is new behavior.

b-morgan commented Dec 5, 2017

I haven't seen any GCode Viewer issues with 1.3.5 so I believe this is new behavior.

@b-morgan

This comment has been minimized.

Show comment
Hide comment
@b-morgan

b-morgan Dec 5, 2017

The GCode Viewer in Safe Mode behaved itself. Guess I'll try again with plugins enabled.

b-morgan commented Dec 5, 2017

The GCode Viewer in Safe Mode behaved itself. Guess I'll try again with plugins enabled.

@ChrisHeerschap

This comment has been minimized.

Show comment
Hide comment
@ChrisHeerschap

ChrisHeerschap Dec 5, 2017

I've confirmed that #2267 is fixed in RC2, thank you! I'll run through the other things to verify what I can.

ChrisHeerschap commented Dec 5, 2017

I've confirmed that #2267 is fixed in RC2, thank you! I'll run through the other things to verify what I can.

@b-morgan

This comment has been minimized.

Show comment
Hide comment
@b-morgan

b-morgan Dec 5, 2017

After reloading (to remove Safe Mode), the GCode Viewer is behaving itself... I'll report again if it (or anything else) is unusual.

b-morgan commented Dec 5, 2017

After reloading (to remove Safe Mode), the GCode Viewer is behaving itself... I'll report again if it (or anything else) is unusual.

@chippypilot

This comment has been minimized.

Show comment
Hide comment
@chippypilot

chippypilot Dec 5, 2017

I've updated and done 3 small prints successfully. no issues to report

chippypilot commented Dec 5, 2017

I've updated and done 3 small prints successfully. no issues to report

@Lordxv

This comment has been minimized.

Show comment
Hide comment
@Lordxv

Lordxv Dec 6, 2017

I will test this ! What Marlin firmware should you at least be running ?

Lordxv commented Dec 6, 2017

I will test this ! What Marlin firmware should you at least be running ?

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Dec 6, 2017

Owner

@Lordxv no specific requirements with regards to Marlin firmware version. In fact, it should also still work just fine not-Marlin firmwares ;)

Owner

foosel commented Dec 6, 2017

@Lordxv no specific requirements with regards to Marlin firmware version. In fact, it should also still work just fine not-Marlin firmwares ;)

@ChrisHeerschap

This comment has been minimized.

Show comment
Hide comment
@ChrisHeerschap

ChrisHeerschap Dec 6, 2017

Several small prints and one 70MB print and still no issues. Ran through other things that I could think of and it's working nicely.

ChrisHeerschap commented Dec 6, 2017

Several small prints and one 70MB print and still no issues. Ran through other things that I could think of and it's working nicely.

@Lordxv

This comment has been minimized.

Show comment
Hide comment
@Lordxv

Lordxv Dec 6, 2017

So i run OctoPrint: 1.3.6rc2 and still got some Error:Line Number is not Last Line Number+1 and
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
The no "Recv" are inconsistent.

It runs on a raspberry pi zero w. And an Anet A8 with Skynet3D (version ??? ). Should i update to OctoPrint: 1.3.5 (stable) ?

PS: should i open an new bug report ?

Lordxv commented Dec 6, 2017

So i run OctoPrint: 1.3.6rc2 and still got some Error:Line Number is not Last Line Number+1 and
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
The no "Recv" are inconsistent.

It runs on a raspberry pi zero w. And an Anet A8 with Skynet3D (version ??? ). Should i update to OctoPrint: 1.3.5 (stable) ?

PS: should i open an new bug report ?

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Dec 6, 2017

Owner

Yes, please open a bug report. And please include all the logs that are requested in the ticket template because otherwise there's no way to look into this. Just from your description though it sounds rather like you might be running into some actual communication issues (line number errors and timeouts are not necessarily a bug in OctoPrint, there are many possible causes for them, and most of them aren't OctoPrint bugs but firmware, power, cabling, ...).

Owner

foosel commented Dec 6, 2017

Yes, please open a bug report. And please include all the logs that are requested in the ticket template because otherwise there's no way to look into this. Just from your description though it sounds rather like you might be running into some actual communication issues (line number errors and timeouts are not necessarily a bug in OctoPrint, there are many possible causes for them, and most of them aren't OctoPrint bugs but firmware, power, cabling, ...).

@Lordxv

This comment has been minimized.

Show comment
Hide comment
@Lordxv

Lordxv Dec 6, 2017

Ok thank you

Lordxv commented Dec 6, 2017

Ok thank you

@andrivet

This comment has been minimized.

Show comment
Hide comment
@andrivet

andrivet Dec 7, 2017

I have printed a few objects without problems (Wanhao i3 Plus with my own firmware based on Marlin 1.1.6). I do have troubles with timelapse but I think it is not related to this RC since I already had it before (I am not able to configure the snapshot URL correctly).

I do not know if it was introduced in this release or in the previous one, but I do like a lot the new GCode vieweer.

andrivet commented Dec 7, 2017

I have printed a few objects without problems (Wanhao i3 Plus with my own firmware based on Marlin 1.1.6). I do have troubles with timelapse but I think it is not related to this RC since I already had it before (I am not able to configure the snapshot URL correctly).

I do not know if it was introduced in this release or in the previous one, but I do like a lot the new GCode vieweer.

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Dec 7, 2017

Owner

I found a small issue (software update plugin persists too much, causing issues when downgrading and potentially more going forward). Also switched octoprint.org and plugins.octoprint.org over to https finally and therefore adjusted all the references to those. That should actually already have been done for the plugin repository, but with the blacklist now I decided it was really about time.

I'll probably push out a third RC with these two changes tomorrow. That should give us another weekend of testing time (which coincides brilliantly with me needing to print some present related things ^^), and if things then still look as rosy as they do now I guess it's time to think about a stable release come next week :)

@andrivet

In what way does "not being able to configure the snapshot URL correctly" express itself? ;) Certainly doesn't sound like a problem with the RC if it's something you've been fighting with longer, but you made me curious.

I do like a lot the new GCode vieweer

It's the same that's been in there since ~2013 🤔

Owner

foosel commented Dec 7, 2017

I found a small issue (software update plugin persists too much, causing issues when downgrading and potentially more going forward). Also switched octoprint.org and plugins.octoprint.org over to https finally and therefore adjusted all the references to those. That should actually already have been done for the plugin repository, but with the blacklist now I decided it was really about time.

I'll probably push out a third RC with these two changes tomorrow. That should give us another weekend of testing time (which coincides brilliantly with me needing to print some present related things ^^), and if things then still look as rosy as they do now I guess it's time to think about a stable release come next week :)

@andrivet

In what way does "not being able to configure the snapshot URL correctly" express itself? ;) Certainly doesn't sound like a problem with the RC if it's something you've been fighting with longer, but you made me curious.

I do like a lot the new GCode vieweer

It's the same that's been in there since ~2013 🤔

@chippypilot

This comment has been minimized.

Show comment
Hide comment
@chippypilot

chippypilot Dec 8, 2017

I think I'm seeing a change of behaviour on the Actual Bed temperature display. This is in both the chart and the table below. At the start of the print there is a delay of >20 seconds before this responds to the temperature from the printer. It is delayed in starting, but then tracks real time, not delayed.The other temps. target and actual are tracking OK.

I'll raise a ticket later when I've done a restart and checked it's still there.

  • correction. it does not display the actual bed temperature until the print starts. actual tool temp. is tracking ok.

chippypilot commented Dec 8, 2017

I think I'm seeing a change of behaviour on the Actual Bed temperature display. This is in both the chart and the table below. At the start of the print there is a delay of >20 seconds before this responds to the temperature from the printer. It is delayed in starting, but then tracks real time, not delayed.The other temps. target and actual are tracking OK.

I'll raise a ticket later when I've done a restart and checked it's still there.

  • correction. it does not display the actual bed temperature until the print starts. actual tool temp. is tracking ok.
@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Dec 8, 2017

Owner

That might be related to how your printer reports your bed temperature. I certainly can't confirm a general issue with bed temperature reporting here. But I know that several firmware variants out there will only output the temperature of the heater it currently waits for heatup on, which means until the blocking heatup of the hotend is done (M109) no other temperatures are reported by the firmware.

Owner

foosel commented Dec 8, 2017

That might be related to how your printer reports your bed temperature. I certainly can't confirm a general issue with bed temperature reporting here. But I know that several firmware variants out there will only output the temperature of the heater it currently waits for heatup on, which means until the blocking heatup of the hotend is done (M109) no other temperatures are reported by the firmware.

@chippypilot

This comment has been minimized.

Show comment
Hide comment
@chippypilot

chippypilot Dec 8, 2017

Thanks for the explanation. I hadn't noticed that behaviour before.

chippypilot commented Dec 8, 2017

Thanks for the explanation. I hadn't noticed that behaviour before.

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Dec 8, 2017

Owner

Marking as closed because 1.3.6rc3 has been released. Comments are still possible though.

New feedback ticket is #2276

Owner

foosel commented Dec 8, 2017

Marking as closed because 1.3.6rc3 has been released. Comments are still possible though.

New feedback ticket is #2276

@foosel foosel closed this Dec 8, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment