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.9rc4 Release Candidate #2745

Closed
foosel opened this Issue Jul 20, 2018 · 29 comments

Comments

Projects
None yet
@foosel
Copy link
Owner

commented Jul 20, 2018

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

@Galfinite

This comment has been minimized.

Copy link

commented Jul 20, 2018

No issues thus far. All is well.

Edit: RPi3B+, Marlin (TH3D_UFW), Creality CR10S

@thess

This comment has been minimized.

Copy link

commented Jul 20, 2018

All is working well on RPi3 + Marlin

@ChrisHeerschap

This comment has been minimized.

Copy link

commented Jul 21, 2018

Sorry I haven't updated on previous RCs - RC4 is installed and has handled several prints with no issues.

@arhi

This comment has been minimized.

Copy link

commented Jul 23, 2018

didn't have time to do many prints these days but all that I did went flawlessly with rc4 (orangepi, smoothieware)

@fieldOfView

This comment has been minimized.

Copy link
Contributor

commented Jul 23, 2018

After updating to RC4 or RC3 (have not tried others) from 1.3.8, OctoPrint fails to start for me.

All plugins that import singledispatch fail to load.

  File "/home/pi/oprint/local/lib/python2.7/site-packages/tornado/gen.py", line 99, in <module>
    from singledispatch import singledispatch  # backport
ImportError: cannot import name singledispatch

The singledispatch module seems to be installed:

$ ~oprint/bin/pip list | grep singledispatch
singledispatch                3.4.0.3

Running Python from the command line, I can import singledispatch, but I can't import singledispatch from singledispatch:

$ ~oprint/bin/python
Python 2.7.13 (default, Nov 24 2017, 17:33:09)
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import singledispatch
>>> from singledispatch import singledispatch
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name singledispatch

Did I somehow end up with a wrong version of singledispatch?

This is on OctoPi version 0.15.0, running on a Raspberry Pi 3.

Update: Somehow both singledispatch and backports_abc got damaged. Reinstalling them both using pip fixed the issue and I am now succesfully running RC4.

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Jul 23, 2018

I can't reproduce this:

pi@octopi3p:~ $ oprint/bin/python
Python 2.7.13 (default, Nov 24 2017, 17:33:09)
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from singledispatch import singledispatch
>>>
pi@octopi3p:~ $ oprint/bin/pip freeze | grep tornado
sockjs-tornado==1.0.3
tornado==4.5.3
pi@octopi3p:~ $ oprint/bin/pip freeze | grep singledispatch
singledispatch==3.4.0.3
@fieldOfView

This comment has been minimized.

Copy link
Contributor

commented Jul 23, 2018

Somehow both singledispatch and backports_abc got damaged on my install. Reinstalling them both using pip fixed the issue and I am now succesfully running RC4.

@kazibole

This comment has been minimized.

Copy link

commented Jul 23, 2018

No issues on Prusa MK3 firmware 3.3.1 monitoring SD card prints.

@JohnOCFII

This comment has been minimized.

Copy link

commented Jul 23, 2018

I've run 2 prints now (13 minute, and 4 hour). Each worked properly. This included Telegram and OctoSlack plugins, plus timelapse too.

@jwg3

This comment has been minimized.

Copy link

commented Jul 24, 2018

Observation: The Print Time Left is consistently larger than the Total Print Time on multi-hour prints. Toward the end of the printing duration, probably under an hour, the time remaining corrects itself. I can run some tests, if you specify how to test this.

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Jul 24, 2018

@jwg3 sounds rather usual, print time left is calculated on the fly and doesn't take acceleration, jerk and other settings into account, that might influence printing speed. Depending on the model, this can mean diverging values. You can try one of the new alternative estimator plugins now that an API is in place for that though :)

@Rapsey

This comment has been minimized.

Copy link

commented Jul 24, 2018

Since updating from RC3 to RC4 I've been getting constant 1-2 second pauses between print moves. I have already eliminated the printer itself (works fine from SD card), the slicer software/settings (old G-Codes that used to work now don't) and the USB cable (replaced it). No errors in OctoPrint, running on a Raspberry Pi 3 B+ (OctoPi) with normal system load. Printer is a CR-10S S4 with a baudrate of 115200.

I am not quite ready to conclude RC4 is the culprit because I have since downgraded back to RC3 (which used to work for me) and the pauses are still there. Nevertheless I thought it prudent to mention it here. Perhaps the auto-update to RC4 updated some libraries which were not automatically downgraded when I went back to RC3?

What I have left to try:

  • Different Pi (will try with a regular Pi 3 B)
  • Different OctoPrint version (still have an SD card with an older version which used to work)
  • Clean reinstall of OctoPi with RC4
  • Clean reinstall of Raspbian + OctoPrint RC4 from source (if all else fails)

I'll keep you posted.

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Jul 24, 2018

The changes from RC3 to RC4 are these commits. There were no updated dependencies (and the auto update mechanism never automatically updates existing dependencies unless a new version is explicitly required) and no changes to the communication layer. The only changes were in the pip helper used for plugin installs, a line of frontend code responsible for enabling the print button, and some changes to the settings API. So if the issue persists even after a downgrade, it feels more like a general issue unrelated to RC4.

What happens if you downgrade to 1.3.8/stable? What does the terminal show during those pauses?

@Rapsey

This comment has been minimized.

Copy link

commented Jul 24, 2018

Interesting, downgrading to 1.3.8/stable resolved the issue. I should note that this time I downgraded by switching the release channel to stable in the WebUI. Last time I did it from the command line:

pi@nzige:~$ ~/oprint/bin/pip install https://github.com/foosel/OctoPrint/archive/1.3.9rc3.zip
pi@nzige:~$ sudo service octoprint restart

Updating back to 1.3.9rc4 now. If the issue returns I will record the terminal output so you can see what happens in real-time.

@Rapsey

This comment has been minimized.

Copy link

commented Jul 24, 2018

Alright, back to 1.3.9rc4 and the pauses have returned. I have recorded it live (apologies for my poor camera work) and also screen-capped the terminal from the beginning of the print to provide a readable version.

Camera: https://youtu.be/L9Ggo6NmbZI
Terminal: https://youtu.be/8HNkNvG8BuU

Note that this particular G-Code is very slow (10mm/s first layer) so the pauses might not be immediately apparent during the skirt. If you listen you can hear them very clearly. In this print I am using both retraction and Z-hop which exaggerates the issue (more actions to pause between) but the pauses also happen without either of those things.

There is no randomness to the pauses: they always happen at the same moments in the print, i.e. between virtually any move. Something like a circle can be drawn in one go. In this particular case the skirt is circular. It draws one full circle of skirt, then pauses, then does another circle of skirt, pauses again etc.

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Jul 24, 2018

Could you please create a serial.log of those pauses? The youtube video of the terminal is really hard to follow.

Actually, best create two serial.logs, one from 1.3.9rc4 with the issue, one from 1.3.8 without the issue, same GCODE file.

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Jul 24, 2018

Also, it looks like those pauses coincide with those M204 and M205 commands and the printer's response to them. Every time your terminal shows them, things slow to a crawl and it also looks like the firmware is taking some time to respond (which would explain the slow down). Are those commands present under 1.3.8 as well? Are they part of the GCODE? If so why are they sent what feels like every couple of seconds? Does the issue persist in safe mode as well?

@Rapsey

This comment has been minimized.

Copy link

commented Jul 24, 2018

They do indeed seem to coincide with those instructions. They are part of the G-code I'm using, I believe this is the handiwork of Cura's acceleration control feature being enabled. However I have always had this feature enabled. I'm using the default firmware that came with the printer.

Currently generating the serial logs, will do one in safe mode as well.

@Rapsey

This comment has been minimized.

Copy link

commented Jul 24, 2018

1.3.9rc4 in safe mode does work, no pauses.

Serial logs:

Now that we have these two, is there still a point in making one for 1.3.8/stable?

These are the only plugins I have installed (this is everything that's grayed out in safe mode):

  • AstroPrint (1.0.13)
  • Navbar Temperature Plugin (0.9)
  • Print History Plugin (1.2)
  • PrintTimeGenius Plugin (1.0.9)
  • TouchUI (0.3.11)

For good measure, here's my entire pip list.

EDIT: I guess I should start enabling plugins one by one until I find the culprit.

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Jul 24, 2018

Now that we have these two, is there still a point in making one for 1.3.8/stable?

No, I don't think so.

I guess I should start enabling plugins one by one until I find the culprit.

That would have been my next suggestion. In any case, since the issue vanishes in safe mode chances are high it's indeed caused by one of the third party plugins. I'd start with PrintTimeGenius, since that is 1.3.9+ exclusive and hence would probably have disabled itself automatically under 1.3.8.

Taking a look at the log:

2018-07-24 12:22:28,009 - Send: N107 G1 X190.148 Y189.074 E1.84505*111
2018-07-24 12:22:28,081 - Recv: ok
2018-07-24 12:22:28,089 - Send: N108 M204 S5000*90
2018-07-24 12:22:28,116 - Recv: Setting Print and Travel Acceleration: 5000.00
2018-07-24 12:22:28,161 - Recv: ok
2018-07-24 12:22:29,023 - Send: N109 M205 X30 Y30*45
2018-07-24 12:22:29,073 - Recv: ok
2018-07-24 12:22:29,891 - Send: N110 G0 F3600 X190.442 Y189.346*64
2018-07-24 12:22:29,902 - Recv: ok
2018-07-24 12:22:29,907 - Send: N111 M204 S500*98
2018-07-24 12:22:29,964 - Recv: Setting Print and Travel Acceleration: 500.00
2018-07-24 12:22:29,981 - Recv: ok
2018-07-24 12:22:30,702 - Send: N112 M205 X20 Y20*39
2018-07-24 12:22:30,763 - Recv: ok

something is causing around 800-900ms of pausing after each M204's ok and once again after the M205 ok. Maybe one of your plugins is triggering something based on those commands and that takes a bit longer. Hard to say though.

In comparison, here's an excerpt from the safe mode log:

2018-07-24 12:34:09,542 - Send: N13 M107*23
2018-07-24 12:34:09,555 - Recv: ok
2018-07-24 12:34:09,558 - Send: N14 M204 S5000*102
2018-07-24 12:34:09,573 - Recv: Setting Print and Travel Acceleration: 5000.00
2018-07-24 12:34:09,576 - Recv: ok
2018-07-24 12:34:09,581 - Send: N15 M205 X30 Y30*17
2018-07-24 12:34:09,589 - Recv: ok
2018-07-24 12:34:09,596 - Send: N16 G0 F3600 X190.148 Y189.074 Z0.12*29
2018-07-24 12:34:09,619 - Recv: ok
2018-07-24 12:34:09,624 - Send: N17 M204 S500*85
2018-07-24 12:34:09,636 - Recv: Setting Print and Travel Acceleration: 500.00
2018-07-24 12:34:09,638 - Recv: ok
2018-07-24 12:34:09,644 - Send: N18 M205 X20 Y20*28
2018-07-24 12:34:09,653 - Recv: ok
2018-07-24 12:34:09,659 - Send: N19 G1 F1800 E0*42
2018-07-24 12:34:09,667 - Recv: ok

~6ms.

@Rapsey

This comment has been minimized.

Copy link

commented Jul 24, 2018

I had just reached the same conclusion. All third-party plugins disabled except for PrintTimeGenius 1.0.9 and there we go, pauses all over. Since the plugin used to work on RC3 but didn't work anymore after downgrading back to it, I assume the bug was introduced in one of the plugin updates that were released in the past few days.

Thank you so much for all your help. This is a truly amazing display of support, especially since it's not even a bug in OctoPrint. I reckon most devs would have simply said said: not our problem. You have taught me much about debugging my own problems in the future and have restored my faith in humanity in the process. Hats off to you!

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Jul 24, 2018

Glad I could help :)

Also just saw this: eyal0/OctoPrint-PrintTimeGenius#54 - sounds like the same issue so maybe you should chime in there!

@Thisismydigitalself

This comment has been minimized.

Copy link

commented Jul 25, 2018

Exactly as @Rapsey commented before me. I've upgraded to 1.3.9.rc4 and printers started printing like communication was interrupted on a sub second intervals. just awful. reverted back to 1.3.6 which is my favorite version to date and all's good. i did not try to find the culprit but i as well suspect that one or some of the plugins i installed caused this as I managed to print a 10 hours long print with 1.3.9.rc4 with no issues before installing new plugs, - at least i think so.

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Jul 25, 2018

@Thisismydigitalself PrintTimeGenius is the culprit ;)

@Thisismydigitalself

This comment has been minimized.

Copy link

commented Jul 25, 2018

@foosel indeed it was. i could not see it in the list of installed plugin since i reverted back to 1.3.6.
Now I'm back again on RC4 and i can see the plug in my list of installed plugins. i will remove it now, test without it, than install the fixed version of it to see if it's any good.

EDIT: Just tested same gcode on 1.3.9rc4 when PrintTimeGenius is NOT installed = No more issues.

Cheers.

@Rapsey

This comment has been minimized.

Copy link

commented Jul 25, 2018

@Thisismydigitalself I have tested the fixed dev version and can confirm that it works. It should be released soon but if you choose to use this dev version you should make sure to uninstall (not just disable) the plugin first. The dev version is still set to 1.0.9 so pip won't install it if you have the original 1.0.9 installed.

EDIT: Fix has now been released as part of version 1.1.0.

@Thisismydigitalself

This comment has been minimized.

Copy link

commented Jul 25, 2018

Thanks @Rapsey for this update. will give 1.1.0 a try.

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Jul 25, 2018

1.3.9 has just been released.

@foosel foosel closed this Jul 25, 2018

@chatrat12

This comment has been minimized.

Copy link

commented Jul 26, 2018

I know I'm late to the party reporting on this one. DId a solid 10 hours of printing on RC4 with no hiccups :)

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.