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

[RC Feedback] Feedback on the 1.3.11rc2 Release Candidate #3103

Closed
foosel opened this issue Apr 4, 2019 · 39 comments

Comments

Projects
None yet
10 participants
@foosel
Copy link
Owner

commented Apr 4, 2019

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

Unreproduced issues

Unreproduced and information for further analysis missing

Plugin issues

@trunzoc

This comment has been minimized.

Copy link

commented Apr 4, 2019

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

This comment has been minimized.

Copy link
Owner Author

commented Apr 4, 2019

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

This comment has been minimized.

Copy link
Owner Author

commented Apr 4, 2019

Never mind, found and fixed for 1.3.11rc3

@b-morgan

This comment has been minimized.

Copy link

commented Apr 4, 2019

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

@CRCinAU

This comment has been minimized.

Copy link

commented Apr 5, 2019

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

@gege2b

This comment has been minimized.

Copy link

commented Apr 5, 2019

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

This comment has been minimized.

Copy link

commented Apr 5, 2019

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

This comment has been minimized.

Copy link
Owner Author

commented Apr 5, 2019

@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

This comment has been minimized.

Copy link

commented Apr 5, 2019

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

This comment has been minimized.

Copy link

commented Apr 5, 2019

@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

This comment has been minimized.

Copy link
Owner Author

commented Apr 5, 2019

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

@arhi

This comment has been minimized.

Copy link

commented Apr 5, 2019

@foosel sent both ids in pp on forum

@arhi

This comment has been minimized.

Copy link

commented Apr 5, 2019

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

This comment has been minimized.

Copy link

commented Apr 5, 2019

Issue #3111 created for this

@JohnOCFII

This comment has been minimized.

Copy link

commented Apr 5, 2019

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

This comment has been minimized.

Copy link

commented Apr 6, 2019

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

This comment has been minimized.

Copy link

commented Apr 7, 2019

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

This comment has been minimized.

Copy link

commented Apr 7, 2019

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

This comment has been minimized.

Copy link

commented Apr 7, 2019

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

This comment has been minimized.

Copy link

commented Apr 7, 2019

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

This comment has been minimized.

Copy link
Owner Author

commented Apr 8, 2019

@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

This comment has been minimized.

Copy link
Owner Author

commented Apr 8, 2019

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 added a commit that referenced this issue Apr 8, 2019

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Apr 8, 2019

@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:

image

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

This comment has been minimized.

Copy link

commented Apr 8, 2019

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

This comment has been minimized.

Copy link
Owner Author

commented Apr 8, 2019

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

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Apr 8, 2019

@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

This comment has been minimized.

Copy link

commented Apr 8, 2019

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

This comment has been minimized.

Copy link

commented Apr 8, 2019

@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

This comment has been minimized.

Copy link
Owner Author

commented Apr 8, 2019

@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

This comment has been minimized.

Copy link

commented Apr 8, 2019

@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

This comment has been minimized.

Copy link
Owner Author

commented Apr 8, 2019

@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

This comment has been minimized.

Copy link

commented Apr 8, 2019

@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

This comment has been minimized.

Copy link

commented Apr 8, 2019

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.

serial

  1. 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

This comment has been minimized.

Copy link

commented Apr 8, 2019

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

This comment has been minimized.

Copy link

commented Apr 8, 2019

@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:

image

@kazibole

This comment has been minimized.

Copy link

commented Apr 9, 2019

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

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Apr 9, 2019

@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

This comment has been minimized.

Copy link

commented Apr 9, 2019

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

@foosel foosel unpinned this issue Apr 11, 2019

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Apr 11, 2019

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

@foosel foosel closed this Apr 11, 2019

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.