[RC Feedback] Feedback on the 1.3.11rc2 Release Candidate

[foosel]

Please provide general feedback on your experience with the 1.3.11rc2 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 not yet listed below the following line, please open a new ticket and follow "How to file a bug report".

---

Currently known issues

• ✔ #3105 - UnicodeDecodeError in virtual printer's readline - fix ready for 1.3.11rc3
• ✔ #3108 - Refactoring error in port detection causing exception if port cannot enter programming mode - fix ready for 1.3.11rc3
• ✔ issue with current version of Octolapse due to removed UI_API_KEY as reported by @FormerLurker - solution ready for 1.3.11rc3
• ✔ #3115 - Serial terminal has extra line breaks -fix ready for 1.3.11rc3
• ✔ #3116 - Print started from printer's LCD panel renders web interface inoperable - fix ready for 1.3.11rc3 (not a regression, but severe enough)

Unreproduced issues

• (✔) #3111 - 1.3.11rc2 disconnect/connect issue - potential fix ready for 1.3.11rc3, still awaiting validation of underlying theory (cannot reproduce locally)

Unreproduced and information for further analysis missing

• ❓ "Print completes but temp data appears to be 'stuck' at last known value for bed and hotend." (1.3.11rc1)

Plugin issues

• ✔ #3112 - PSU Control no longer works in 1.3.11rc2 - plugin issue, resolved by new plugin version

[trunzoc]

I am unable to connect to the Virtual Printer on my "Sandbox" OctoPi.

A connection attempt seems to be made and succeed, but then immediately goes back to a disconnected state.

State: Offline (Error: UnicodeDecodeError: ''ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128)' @ comm.py:_readline:2730)
octoprint.log
serial.log

[foosel]

Ah, I saw that in Sentry. Can you share your virtual printer settings in config.yaml? The issue for you running into this might be in there.

[foosel]

Never mind, found and fixed for 1.3.11rc3

[b-morgan]

Upgraded from 1.3.11rc1 on two systems (only one has an actual printer attached).

[CRCinAU]

Updated from 1.3.10 -> 1.3.11-rc2. Seems ok so far.

[gege2b]

Right after the update, I was unable to connect to my printer

2019-04-05 12:09:32,063 - octoprint.util.comm - ERROR - Unexpected error while connecting to serial port: /dev/ttyUSB0 SerialException: '[Errno 11] Could not exclusively lock port /dev/ttyUSB0: [Errno 11] Resource temporarily unavailable' @ comm.py:_openSerial:2603 (hook default)
Traceback (most recent call last):
  File "/home/pi/OctoPrint/venv/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 2603, in _openSerial
    serial_obj = factory(self, self._port, self._baudrate, settings().getFloat(["serial", "timeout", "connection"]))
  File "/home/pi/OctoPrint/venv/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 2592, in default
    serial_obj = serial.Serial(**serial_port_args)
  File "/home/pi/OctoPrint/venv/local/lib/python2.7/site-packages/serial/serialutil.py", line 240, in __init__
    self.open()
  File "/home/pi/OctoPrint/venv/local/lib/python2.7/site-packages/serial/serialposix.py", line 272, in open
    self._reconfigure_port(force_update=True)
  File "/home/pi/OctoPrint/venv/local/lib/python2.7/site-packages/serial/serialposix.py", line 312, in _reconfigure_port
    raise SerialException(msg.errno, "Could not exclusively lock port {}: {}".format(self._port, msg))
SerialException: [Errno 11] Could not exclusively lock port /dev/ttyUSB0: [Errno 11] Resource temporarily unavailable

It worked in safe mode through, and after some restart and reboot, issue seems to have vanished and all works fine from now (no print done yet)

Note : before this error, I tested connecting to a virtual printer (and get the unicode bug witch is already solved)

[arhi]

3 prints (~1h each) done, having issue with connecting to printer, when I do "motors off" my printer disconnects from usb (that's expected), normally, before rc2, I click connect and everything works ok, with rc2, I click connect - nothing happens, need to unplug the printer from octoprint and plug back in for connect to work

[foosel]

@arhi Did the same happen in RC1? Also please provide octoprint.log and serial.log. We might have to open a bug report for that.

@gege2b I saw that in Sentry. It seems to be related to the new exclusive flag added in #3036 by @DanielJoyce. I'm wondering if what @arhi has run into is related and if it might make sense to make this flag optional for now instead of hardcoded, especially since I saw some other connection errors pop up in Sentry that could be caused by this.

[CRCinAU]

I can't duplicate with RC2... I've been printing for a while, hit Disconnect, waited a second, then hit Connect again... Worked ok, no errors logged...

Something else doing it?

[arhi]

@foosel did not notice that with RC1 but can't say 100% :(

log ... I see this "post festum", I already closed octoprint page after last print and I started it now (not touching printer in the meantime) and this is what I see:

Changing monitoring state from "Printing" to "Finishing"
Send: N60223 M400*34
Recv: ok

Send: N60224 M104 S0*103
Recv: ok

Send: N60225 M140 S0*102
Recv: ok

Send: N60226 G0X0Y144Z130*65
Recv: ok

Send: N60227 M84*30
Recv: ok

Changing monitoring state from "Finishing" to "Operational"

Send: M105

Recv: 
Recv: 
Recv: 
Recv: 
Recv: 
Recv: 
Recv: 
Recv: 
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:
Recv:

serial.log itself is not enabled ... I'll be running new print soon so I'll put more info here

edit by @foosel fixed formatting

[foosel]

@arhi Do you have error tracking enabled? If so, please give me your UUID. Maybe there's something helpful in Sentry.

[arhi]

@foosel sent both ids in pp on forum

[arhi]

nothing in serial log ... end of print as expected:

Send: N60227 M84*30Recv: ok

Send: N60228 M105*41

Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2730Please see https://faq.octoprint.org/serialerror for possible reasons of this.Changing monitoring state from "Finishing" to "Offline (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2730)"Connection closed, closing down monitor

and now when I click on "connect" nothing happens.

2019-04-05 18:24:39,469 - octoprint.util.comm - ERROR - Unexpected error while reading from serial port
Traceback (most recent call last):
  File "/home/pi/OctoPrint/venv/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 2730, in _readline
    ret = self._serial.readline()
  File "/home/pi/OctoPrint/venv/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 4819, in readline
    c = self.read(1)
  File "/home/pi/OctoPrint/venv/local/lib/python2.7/site-packages/serial/serialposix.py", line 501, in read
    'device reports readiness to read but returned no data '
SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
2019-04-05 18:24:39,561 - octoprint.util.comm - ERROR - Please see https://faq.octoprint.org/serialerror for possible reasons of this.
2019-04-05 18:24:39,626 - octoprint.util.comm - INFO - Changing monitoring state from "Finishing" to "Offline (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2730)"
2019-04-05 18:25:38,902 - tornado.access - WARNING - 400 POST /api/connection (::ffff:192.168.89.6) 102.36ms
2019-04-05 18:25:47,946 - tornado.access - WARNING - 400 POST /api/connection (::ffff:192.168.89.6) 98.58ms

[arhi]

Issue #3111 created for this

[JohnOCFII]

1.3.11rc2 is working well for me.

• Upgraded from 1.3.10 - OK
• Connected to Prusa i3 MK3 running (somewhat older) 3.4.1 firmware. - OK
• Completed two small prints - OK
• Confirmed time-lapse functioned as expected - OK
• Confirmed GCODE viewer worked as expected - OK
• Confirmed that Print History plugin worked as expected - OK
• Confirmed OctoSlack plugin worked as expected - OK
• Confirmed Telegram plugin worked as expected - OK

Connected and disconnected OctoPrint from printer and reconnected successfully 4 times - OK

[vfrdirk]

Huh. Upgraded one of my Pi units to RC2 from a prior stable build, although I don't recall which one. Now when I start a print job, the printer immediately changes from Printing to Cancelling to Operational state and shuts down the heating elements. I have 1.3.10 on another printer (so I think that's what was on my affected Pi before upgrading, but I can't be sure) and that is still working as expected. Let me know what additional info I can supply, but here are octoprint and serial logs, showing the Print/Cancel sequence.

serial (1).log
octoprint (2).log

[JohnOCFII]

Huh. Upgraded one of my Pi units to RC2 from a prior stable build, although I don't recall which one. Now when I start a print job, the printer immediately changes from Printing to Cancelling to Operational state and shuts down the heating elements. I have 1.3.10 on another printer (so I think that's what was on my affected Pi before upgrading, but I can't be sure) and that is still working as expected. Let me know what additional info I can supply, but here are octoprint and serial logs, showing the Print/Cancel sequence.

You have many active plug-ins. Does this problem happen when running in safe mode?

[JohnOCFII]

An observation -- Both the Telegram and OctoSlack plug-ins used to note connecting to, and losing connection from the printer. Neither are doing that now. Has the messages those plug-ins used for those actions changed?

[FormerLurker]

The 'Detect incomplete startups and set safe mode flag for next startup.' feature seems to work a little too well for development :) I've been working on some startup stuff in my plugin, and I often break/cancel startup, which prevents my plugin from loading on the next run. In a real-world situation this is a good thing, but during development I have to reboot often. Is there some way to disable this feature?

[vfrdirk]

You have many active plug-ins. Does this problem happen when running in safe mode?

Confirmed that a Safe Mode restart allows printing to commence normally, so this is related to a plugin. Is there a best practice approach to re-enabling plugins to isolate the problem child? Is that out of scope for Release Candidate feedback?

[foosel]

@FormerLurker

The 'Detect incomplete startups and set safe mode flag for next startup.' feature seems to work a little too well for development :) I've been working on some startup stuff in my plugin, and I often break/cancel startup, which prevents my plugin from loading on the next run. In a real-world situation this is a good thing, but during development I have to reboot often. Is there some way to disable this feature?

No. But you know what, it makes sense to change that. edit: done, see de6d1af

@vfrdirk

Is there a best practice approach to re-enabling plugins to isolate the problem child? Is that out of scope for Release Candidate feedback?

Disable one by one and test in between. Start with the most likely culprits (in your case plugins that interact with the printer).

It's certainly not outside of the scope of RC feedback to know if there are backwards compatibility issues with plugins, especially if it's with plugins that use documented parts of the API.

@JohnOCFII

An observation -- Both the Telegram and OctoSlack plug-ins used to note connecting to, and losing connection from the printer. Neither are doing that now. Has the messages those plug-ins used for those actions changed?

Hm... not intentionally. I don't know how they track that but I'll check if maybe there was a change in the event triggering here, which would be the most likely candidate for tracking that.

[foosel]

I am unable to connect to the Virtual Printer on my "Sandbox" OctoPi.

A connection attempt seems to be made and succeed, but then immediately goes back to a disconnected state.

State: Offline (Error: UnicodeDecodeError: ''ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128)' @ comm.py:_readline:2730)

For the record, anyone running into this aka #3105 in RC2, take a look at this workaround until RC3 is out.

[foosel]

@FormerLurker

Flag added, server.ignoreIncompleteStartup.

@JohnOCFII

I just quickly installed and setup this slack plugin for a test (the other one didn't look like it supported connection messages based on its sources) and I get messages:

Also tried an error scenario (simulated SerialTimeout) and that also triggered a message. I had to enable these messages in the options though.

I didn't see anything in the Telegram plugin's source that hinted at messages on connect/disconnect 🤔

[b-morgan]

I have a problem with a new plugin I'm developing. I assumed it was somehow my fault but with the recent posts here about plugin problems and the strange nature of my failure (It was almost working and then a minor change (to the almost part) and the whole thing doesn't work anymore). The issue is (https://community.octoprint.org/t/help-with-attributeerror-fanspeedmirror-object-has-no-attribute-m106command/8828). How do I revert to 1.3.10 to verify that it is really my fault?

(I did fall victim to the "Detect incomplete startups...")

[foosel]

@b-morgan see here. I put this link into every single release announcement on the OctoBlog ;)

[foosel]

@b-morgan as just commented in that forum topic, I cannot reproduce the issue you are seeing there here. Though I have to say, it's bad form to not declare variables in __init__ because it can lead to this exact kind of problems. For some reason that part in your code is commented out, and also contains a trailing , that doesn't belong.

[JohnOCFII]

Thanks for checking.

@JohnOCFII

I just quickly installed and setup this slack plugin for a test (the other one didn't look like it supported connection messages based on its sources) and I get messages:

[FormerLurker]

@foosel, thanks for adding that flag! I'll let you know how it works during the next RC.

I also have a quick question about Python3 support in this RC. Is it supported, or is there another development version I should be using?

[foosel]

@FormerLurker Py3 is devel branch/1.4.0.dev, 1.3.x doesn't and will not be compatible to that. 1.4.0rc1 is still a couple months out since I'm also working on some other bigger construction sites for 1.4.0.

[b-morgan]

@foosel Thanks for the hints and I now have the plugin working on both 1.3.10 and 1.3.11rc2. Now back to the tutorial to stumble through creating the github repository and beyond!

[foosel]

@b-morgan

@foosel Thanks for the hints and I now have the plugin working on both 1.3.10 and 1.3.11rc2. Now back to the tutorial to stumble through creating the github repository and beyond!

You are welcome, but what turned out to be the problem now? Something in your plugin or something in RC2 after all?

[b-morgan]

@foosel It was something in the plugin.

I uncommented the "def init(self)" and changed FanSpeedMirror.js to match the plugin I was using as a template. I'm a bit confused about the parameters to the ViewModel and the parameters on the class statement in init.py but since it works, my education can come later.

I'm still working on the github repository and submitting for publication.

[kazibole]

I may have run into two issues. I will have to do more testing with different versions in safe mode to collect better information and logs, but thought I should at least post a note now.

I have a Prusa MK3 running firmware 3.7.0.

1. I initiate an SD card print from the printer's control panel. While printing, I will see a lot of blank "Recv:" lines in the terminal. I do not recall seeing this in 1.3.11rc1 or 1.3.10 but will have to confirm on those versions.

2. I also downgraded from 1.3.11rc2 to 1.3.10 to see if the issue above still occurred. While an SD card print (started from the printer's control panel) is printing, the web GUI will become unresponsive. The serial.log still reflects the correct communication up to the end of the print. The octoprint.log shows:

Traceback (most recent call last):
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/printer/standard.py", line 1346, in _work
    data = self.get_current_data()
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/printer/standard.py", line 1356, in get_current_data
    self._progress = self._get_current_progress()
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/printer/standard.py", line 1282, in _get_current_progress
    return self._on_get_progress()
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/printer/standard.py", line 793, in _updateProgressDataCallback
    statisticalTotalPrintTimeType)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/printer/estimation.py", line 106, in estimate
    estimatedTotalPrintTime = self.estimate_total(progress, cleanedPrintTime)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/printer/estimation.py", line 166, in estimate_total
    return self._data.update(printTime / progress)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/printer/estimation.py", line 207, in update
    if -1.0 * self._threshold < self.average_distance < self._threshold:
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/printer/estimation.py", line 239, in average_distance
    return sum(self._distances) / len(self._distances)
ZeroDivisionError: division by zero

[trunzoc]

Never mind, found and fixed for 1.3.11rc3

I am so sorry for the delay. I was out of town all weekend and just got a chance to check back in.

Thank you for identifying and fixing!

[b-morgan]

@foosel I believe I have completed the submission process for FanSpeedMirror. Is the submission process completely automated or is there a manual final acceptance? If so, I assume that's you and you will get:

[kazibole]

@foosel I opened #3115 and #3116 after doing more testing. Please let me know if you require more information.

[foosel]

@b-morgan manual final acceptance involving a mini review as well. So it might be a bit (this week, but not necessarily today) until I get around to it because RC and other maintenance code work takes precedence.

@kazibole thanks, I'll take a look

[b-morgan]

@foosel No rush. I'm still working on documentation.

[foosel]

1.3.11rc3 has been released, new feedback ticket is here.