OctoPi 0.17.0 RC1 Status

[guysoft]

First release candidate

Please try the release candidate. Download it at: https://storage.googleapis.com/octoprint/2019-10-29_2019-09-26-octopi-buster-lite-0.17.0.zip

Md5: 8a550602b8ccc5df8381924757f88ab9.

Changes in the image

• Raspberrypi 4B support
• linux 4.19.75 from new base image 2019-09-26-raspbian-buster-lite
• OctoPrint 1.3.12
• Fix Chinese Endoscope 8mm ( #602 )
• Bug fixes

Build notes

• Uses CustomPiOS in devel (which I release once I understand how to get the multi-arch tagged correctly)
• Our nightly/release builds have moved to the new build server, after 6+ years of operating.

[drifkind]

Nice timing, as I was about to try installing OctoPrint from scratch on an RPi 4. No apparent differences from the 0.16 install (except for working on the 4). It's now humming along on an Ender 3 Pro, 8 hours into a print (which the RPi 3 would never have managed without falling over).

Later that day: Still going, no glitches.

[dan-and]

I did exactly that yesterday :-O ... Well no problem after all

[ChaosFog]

Ich würde es gerne mit dem Raspberrypi 3 testen.

[dk5ee]

Hi, many thanks for octoprint/octopi. I killed my octopi 0.16.0 recently with 'apt upgrade', after which no wifi was working, so as I wanted to set up fresh octopi I just went to 0.17.0 rc1. steps i did:

1. download and burn to new micro sd card
2. edit 'octopi-wpa-supplicant.txt' and add empty 'ssh' file to /boot - don't know if the ssh file is still necessary.
3. to make transition easier, I copied the folder /home/pi/.octoprint to the new sd card. (I made a mistake there: the ownership of the files must be kept)

Looks like it is working, octoprint shows my ender3 settings. Will try to print out a thing is made with openscad/slic3er gcode.

Again: thanks.

[RyanBalfanz]

Nice timing, as I was about to try installing OctoPrint from scratch on an RPi 4. No apparent differences from the 0.16 install (except for working on the 4). It's now humming along on an Ender 3 Pro, 8 hours into a print (which the RPi 3 would never have managed without falling over).

Later that day: Still going, no glitches.

@drifkind Do you have any idea why it may have been falling over before?

I've never had a problem with OctoPrint from within a container environment (not running from an OctoPi image, but rather as seen at https://github.com/RyanBalfanz/balena-octoprint) so am curious to learn more before attempting to switch.

[guysoft]

Looks so far like its nearly been a week out and everyone is happy, so prepare for a release. Unless anyone speaks up

[git-n-pissed]

I installed OctoPi on a Raspberry Pi 4 with Klipper and used it on my Ender 3. Everything seems to go well except that when press the "Cancel" button during a build, homing is lost. The "OctoKlipper" section in the left menu indicates the connection is still good, as does the output on in the "Terminal" tab, but for some reason homing is lost so I have re-home all axis before I can proceed.

[dplummer]

@guysoft I've got this installed on a Raspberry Pi 4B connected to a Prusa i3 MK3S. Printing works well, but when I goto the plugin manager it says "The pip command could not be found or does not work correctly for this installation of OctoPrint - please consult the log file for details and if necessary configure it manually". Checking the logs I see:

2019-11-04 14:00:25,223 - octoprint.server.api - ERROR - Error calling SimpleApiPlugin pluginmanager
Traceback (most recent call last):
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/server/api/__init__.py", line 68, in pluginData
    response = api_plugin.on_api_get(request)
  File "/home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/pluginmanager/__init__.py", line 280, in on_api_get
    if refresh_repository or not self._is_repository_cache_valid():
  File "/home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/pluginmanager/__init__.py", line 797, in _is_repository_cache_valid
    return mtime + self._repository_cache_ttl >= time.time() > mtime
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'
2019-11-04 14:00:25,228 - tornado.access - ERROR - 500 GET /api/plugin/pluginmanager (::ffff:192.168.1.7) 8.59ms

Edit: This appears to be caused by a network issue. The _repository_mtime is initially set by fetching the plugin repo from a url, I'm guessing that failed. I can confirm other network access works, so this may be unrelated. I'll try rebooting after this print is done.

[guysoft]

@foosel cc know what is going on for @dplummer ? looks like self._repository_cache_ttl can be None

[foosel]

@dplummer please open a bug report in the OctoPrint repository, this is unrelated to OctoPi: https://github.com/foosel/OctoPrint/issues

looks like self._repository_cache_ttl can be None

And I'm fairly sure it's mtime that's None here, not the setting value ;)

[guysoft]

Everything seems to go well except that when press the "Cancel" button during a build, homing is lost

@git-n-pissed pretty sure that's normal behaviour of OctoPrint which has only a single thread to control the printer unless @foosel says otherwise

[foosel]

Doesn't have anything to do with threads... default cancel code (which you can edit to adjust) contains releasing the stepper hold, which will also mean a position loss which in turn will usually also mean a homing loss. If you want it to behave differently here, adjust the GCODE scripts to your liking.

[git-n-pissed]

Doesn't have anything to do with threads... default cancel code (which you can edit to adjust) contains releasing the stepper hold, which will also mean a position loss which in turn will usually also mean a homing loss. If you want it to behave differently here, adjust the GCODE scripts to your liking.

Thanks for the education. I'm coming from a CNC world where homing is essentially never lost unless the machine loses power, so this just seemed strange to me. I see that by default the GCODE generated by Cura re-homes at the beginning of each print job as well, which makes this a non-issue.

[guysoft]

Releasing

[guysoft]

https://github.com/guysoft/OctoPi/releases/tag/0.17.0

[markddavidoff]

I was able to workaround this by disabling the plugin blacklist and restarting octopi.

[drifkind]

@drifkind Do you have any idea why it may have been falling over before?

A bit late replying but for the record, it was an unrelated problem only exposed by OctoPrint.