Octoprint: [RC Feedback] Feedback on the 1.3.9rc3 Release Candidate

[foosel]

Please provide general feedback on your experience with the 1.3.9rc3 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".

[CapnBry]

While rc2 installed with no fuss, updating to rc3 failed for me

2018-07-16 14:06:49,010   /home/pi/OctoPrint/venv/bin/python -m pip install https://github.com/foosel/OctoPrint/archive/1.3.9rc3.zip --no-cache-dir
2018-07-16 14:06:53,773 !
2018-07-16 14:06:53,775 ! Usage:
2018-07-16 14:06:53,775 ! /home/pi/OctoPrint/venv/bin/python -m pip install [options] <requirement specifier> ...
2018-07-16 14:06:53,776 ! /home/pi/OctoPrint/venv/bin/python -m pip install [options] -r <requirements file> ...
2018-07-16 14:06:53,777 ! /home/pi/OctoPrint/venv/bin/python -m pip install [options] [-e] <vcs project url> ...
2018-07-16 14:06:53,777 ! /home/pi/OctoPrint/venv/bin/python -m pip install [options] [-e] <local project path> ...
2018-07-16 14:06:53,778 ! /home/pi/OctoPrint/venv/bin/python -m pip install [options] <archive url/path> ...
2018-07-16 14:06:53,778 !
2018-07-16 14:06:53,779 ! no such option: --no-cache-dir

I had to upgrade my virtualenv's pip manually from the command line. After that, the rc3 upgrade worked fine.

pi@prontwoer:~/OctoPrint $ ./venv/bin/pip install --upgrade pip
Downloading/unpacking pip from https://files.pythonhosted.org/packages/0f/74/ecd13431bcc456ed390b44c8a6e917c1820365cbebcb6a8974d1cd045ab4/pip-10.0.1-py2.py3-none-any.whl#sha256=717cdffb2833be8409433a93746744b59505f42146e8d37de6c62b430e25d6d7
  Downloading pip-10.0.1-py2.py3-none-any.whl (1.3MB): 1.3MB downloaded
Installing collected packages: pip
  Found existing installation: pip 1.5.6
    Uninstalling pip:
      Successfully uninstalled pip
Successfully installed pip
Cleaning up...

Shhhoooould we be doing some sort of virtualenv maintenance, upgrading it from time to time?

[brandstaetter]

I had upgraded my pip before, cause the warnings annoyed me... so the upgrade went well.

[foosel]

@CapnBry You must be running a somewhat ancient setup there that your version of pip didn't yet support --no-cache-dir O_O

Shhhoooould we be doing some sort of virtualenv maintenance, upgrading it from time to time?

Can't hurt.

I fear I'll have to do a version check here though to work around this issue in the field - $deity knows how many installs are out there with ancient pip versions which would then run into issues down the road. Which means another RC sometime this week (I hope). Hooray ;)

Same btw for the plugin install commands, which also got this added. For newer pip versions, this is the only thing that apparently helps against a weird MemoryError on low memory systems caused by the newer pip's caching mechanism. 1.3.9rc2 added that flag to the update process as well, since the same pip bug can cause problems there, and that's why you only now ran into it when attempting to upgrade from that version.

[FormerLurker]

I'm having a cancellation issue on rc3. I have been running test prints all morning and I had a lockup after canceling my latest test. Here are the terminal logs:

Send: N13792 G1 Z0.500 F7200*20
Send: N13793 G90*31
Recv: ok
Send: N13794 G1 X123.500 Y103.500*35
Send: N13795 M400*46
Recv: ok
Recv: ok
Send: N13796 M114*45
Changing monitoring state from "Printing" to "Cancelling"
Recv: echo:busy: processing
Recv: ok
Recv: X:123.50 Y:103.50 Z:42.70 E:915.10 Count X: 123.94 Y:102.94 Z:42.99
Recv: ok
Send: N13797 M105*44
Recv: ok T:210.0 /210.0 B:60.0 /60.0 T0:210.0 /210.0 @:78 B@:41
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.
Send: N13798 M105*35
Recv: ok T:210.0 /210.0 B:60.0 /60.0 T0:210.0 /210.0 @:78 B@:47
Send: N13799 M105*34
Recv: ok T:210.1 /210.0 B:60.1 /60.0 T0:210.1 /210.0 @:76 B@:36Communication 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.
Send: N13800 M105*45

This keeps repeating. The 'Cancel Gcode' script from OctoPrint doesn't appear to have executed since my bed/extruder temps didn't change. The printer is a Prusa Mk2S w/mmu.

Disconnecting and reconnecting the printer worked. Let me know what additional logs you want, and let me know if you want to create a new issue for this. I will be running more tests and can collect any data you need. I'll attempt to debug, but might not have time until later this week.

[FormerLurker]

After I posted the last message I heard some strange noises from my printer. I noticed that some additional gcode executed after I had disconnected and reconnected my printer. The code is from Octolapse, and must have been sitting there waiting to execute, but never received a position request. This triggered a timeout, which caused the 'end snapshot' gcode to be sent. Here are the logs, which took place many minutes after I reconnected my printer:

Send: G1 X120.632 Y100.632
Recv: ok
Send: G91
Send: G1 Z-0.500
Recv: ok
Recv: ok
Send: G1 E4.00000 F3000
Send: G90
Recv: echo: cold extrusion prevented
Recv: ok
Send: G1 F900
Recv: ok
Send: G1 X129.368 Y100.632 E0.29570
Recv: ok
Recv: echo: cold extrusion prevented
Recv: ok
Send: M105

This is probably related to Octolapse, but I'll try to verify ASAP. I'll review this as free time pops up and will post back more info.

[gege2b]

I didn't do real print for now, but my 2 or 3 tests with the virtual printer seems to confirm that #2677 could be solved, because all of my failed prints before was run without problem now :+1:

[FormerLurker]

@foosel, good news: It's looking like the cancel issue is on my end. I'll continue testing.

[buchnoun]

All is fine for me so far, except I can't get rid of the safety notice for my printer (i3 MEGA). I would appreciate to be able to remove that red box from the interface... Thanks anyway for your beautiful software ;-)

[foosel]

@buchnoun see the FAQ. It's intentional that it's not trivial to disable this.

[buchnoun]

I've read the FAQ thanks, but know that I'm aware of this issue it's a bit annoying to not being able to discard the warning, that's all I'm saying. Would you like to be reminded that driving is dangerous whenever you start your car?

[four-of-four]

This release came just in time for me. A few days ago I had just started to play with OctoLapse plugin under Stable Release.
Everything working fine.
Then, I decided to moved up to Maintenance RC Channel and got 1.3.9rc2. And my very next print froze. I had to power cycle the Anet A8. Tried again....same result....froze during the print. Had to cycle power. Gave up and rolled back to Stable Channel. Woke up this morning and saw this rc3 version and read the release notes. I upgraded to 1.3.9rc3 and tried a new prin; all went well. No issues with the printer or Octolapse. Both the print and video came out great. Thank you for fixing this issue so quickly.

[foosel]

Would you like to be reminded that driving is dangerous whenever you start your car?

Yes, if that car is at risk of bursting into flames, definitely. Fix the underlying issue instead of ignoring it.

The FAQ includes the info on how to get rid of the message at your own risk.

[gege2b]

@buchnoun here's a quote of the FAQ :

"If you want this message gone, fix the underlying safety issue. If that isn't an option for whatever reason (or you believe that the message is displayed erroneously), you can disable the bundled "Printer Safety Check" plugin, which is responsible for this message. Be advised though that you are actively ignoring an actual safety issue with your printer this way.

It's your own responsibility to keep your printer safe."

As long as you know your printer is risky, you need to not forget that point

Personnally I use a vertical drawing bot with an instance of Octoprint, this polarbot runs repetier<0.92 witch is known to not have thermal safety, and disabling this plugin was indeed the only way to get rid of this warning (wich is useless in my particular case because, well... there are no heaters at all)

But I agree with @foosel, as long as your printer is not safe, warning shouldn't be disabled (like the "bip" "bip" on a car when you didn't attach your seatbelt)

[gege2b]

I found a little bug while testing this rc3 but I don't think it appeared now

I use the virtual printer to check for the #2677 and I realized that if I connect to the virtual printer, close the brower tab, open a new one and go to the octoprint UI, the selected/connected printer is my "real" printer

Every commands (setting temperature, mainly) are still sent to the virtual printer anyway

[kazibole]

Have completed a few SD card prints on my Prusa MK3 with OctoPrint 1.3.9-rc3 monitoring without any issues (both initiated from the LCD control panel and OctoPrint).

[chatrat12]

So far, so good. Things are running smoothly.

[foosel]

@gege2b Hm... doesn't sound like a show stopper, but still something I'll take a look at for 1.3.10. I observed this with the new comm layer (unsurprisingly, still a lot of small stuff to fix on that one) but that something similar happens on 1.3.x as well is news.

Could you open a proper ticket for that?

[foosel]

New release candidate, new feedback ticket: #2745