OctoPi 0.14.0 RC1 status

[guysoft]

Please try the release candidate.
Download it at:
https://storage.googleapis.com/octoprint/2017-03-31_2017-03-02-octopi-jessie-lite-0.14.0.zip
md5:
https://storage.googleapis.com/octoprint/2017-03-31_2017-03-02-octopi-jessie-lite-0.14.0.zip.md5

It is built against Raspbian 2017-03-02 (Release Notes)

Changes in the image

• Added note to /root/bin/webcamd to use octopi.txt for configuration
• Added note to octopi-network.txt for Mac OS X users to not use Textedit/properly configure Textedit
• Added note with further instructions on usage to boot and login screen
• Allow configuration of mulitple wifi networks via octopi-wpa-supplicant.txt
• Better "service not running" error pages
• Enabled SSH by default (we usually run headless, disabling it is not an option)
• Updated stock config.yaml and init script for OctoPrint to 1.3.0+
• Updated install-desktop script to only pull in needed packages
• Fixes:
  • Prevent NTP updates from failing on RPi3 wifi (Prevent NTP updates from failing on RPi3 wifi #327)
  • Prevent weird SSH issues on RPi3 (Suggestion: add "IPQoS 0x00" to "/etc/ssh/sshd_config", Rpi3, WiFi SSH issue #294])
  • Prevent duplicate X-Scheme headers in haproxy [Double reverse proxies with https lead to double X-Scheme headers generated by haproxy #239)
  • Workaround for an issue with recent pip versions and pyasn1 (New pip 9 breaks install of pyasn1 #276)

Note:
In 0.13.0 we promised new variant for more arm devices support. The has been a achieved with the new Armbian variant. With it, all the devices listed here support OctoPi, but since we didn't get a call for a specific device, we are not maintaining a build at the moment.

[dbvandy]

Print jobs crash with USB mouse and keyboard attached. This should be notated in description.

I have disconnected mouse and keyboard from Pi Zero W and all seems well...

[guysoft]

@dbvandy Ok please dont spam the thread, If you have new information please edit an existing thread and type "update:" with the new information you want to add.
I am editing your messages to make them readable.

[guysoft]

@foosel Is this a no-go for the feature?
#336

[foosel]

@dbvandy What kind of mouse and keyboard and what kind of printer? I have not seen this behaviour in my own tests. Power issue? What does "Print jobs crash" mean, what happens exactly?

@guysoft #336 at least sounds like we need some kind of workaround for the current raspi-config behaviour, otherwise IMHO no-go. Will comment there.

[dbvandy]

Standard usb keyboard, Logitech m510 wireless mouse, delta kossel 180x280 printer running marlin. The 16 command buffer ran down frequently and then finally ran out causing the printer to quit. After removing the keyboard and mouse from the passive usb hub, the printer did not hit the buffer much if at all. I would assume that the limited memory and processing power of the zero w cause the processor to get overwhelmed with the multiple usb devices. I am not aware of a way to monitor the cpu processes on the pi to verify that it is bogging. I can reproduce this effect by reconnecting the keyboard and mouse to the hub. This is some of the output when the printer is buffering and stuttering: Send: N1429 G1 X19.316 Y16.397 E112.78947*93 Recv: T:224.26 /225 @:157 Recv: ok 1429 Send: N1430 G1 X19.215 Y16.773 E112.80242*80 Recv: Error:Wrong checksum Recv: Recv: Resend:1430 Recv: ok Send: N1430 G1 X19.215 Y16.773 E112.80242*80 Recv: Error:Format error Recv: Recv: Resend:1430 Recv: ok Send: N1430 G1 X19.215 Y16.773 E112.80242*80 Recv: Error:Format error Recv: Recv: Resend:1430 Recv: ok Send: N1430 G1 X19.215 Y16.773 E112.80242*80 Recv: Error:Format error Recv: ok 1429 Send: N1431 G1 X19.087 Y17.098 E112.81403*89 Recv: Error:Format error Recv: ok 1429 Send: N1432 G1 X18.919 Y17.422 E112.82617*84 Recv: Unknown command: Recv: Recv: Resend:1430 Recv: ok Send: N1430 G1 X19.215 Y16.773 E112.80242*80 Recv: Unknown command: Recv: Error:Wrong checksum Recv: Recv: Resend:1430 Recv: ok Send: N1431 G1 X19.087 Y17.098 E112.81403*89 Recv: ok 1430 Send: N1432 G1 X18.919 Y17.422 E112.82617*84 Recv: ok 1431 Send: N1433 G1 X18.727 Y17.712 E112.83774*83 Recv: ok 1432 Send: N1434 G1 X18.493 Y17.997 E112.85001*88 Recv: ok 1433 Send: N1435 G1 X18.251 Y18.235 E112.86129*85 Recv: ok 1434 Send: N1436 G1 X17.696 Y18.638 E112.88411*95 Recv: ok 1435 Send: N1437 G1 X17.381 Y18.798 E112.89586*88 Recv: ok 1436 Send: N1438 G1 X17.022 Y18.933 E112.90861*94 Recv: ok 1437 Send: N1439 G1 X16.362 Y19.074 E112.93106*89 Recv: ok 1438 Send: N1440 G1 X-15.709 Y19.094 E113.99775*119 Recv: ok 1439 Send: N1441 G1 X-16.338 Y19.076 E114.01868*122 Recv: ok 1440 Send: N1442 G1 X-16.691 Y19.022 E114.03055*122 Recv: ok 1441 Send: N1443 G1 X-17.067 Y18.921 E114.04350*127 Recv: ok 1442 Send: N1444 G1 X-17.392 Y18.793 E114.05512*119 Recv: ok 1443 Send: N1445 G1 X-17.717 Y18.625 E114.06729*122 Recv: ok 1444 Send: N1446 G1 X-18.013 Y18.429 E114.07910*126 Recv: ok 1445 Send: N1447 G1 X-18.286 Y18.204 E114.09086*112 Recv: ok 1446 Send: N1448 G1 X-18.530 Y17.956 E114.10244*114 Recv: ok 1447 Send: N1449 G1 X-18.752 Y17.677 E114.11429*117 Recv: ok 1448 Send: N1450 G1 X-18.952 Y17.363 E114.12668*119 Recv: ok 1449 Send: N1451 G1 X-19.102 Y17.061 E114.13789*116 Recv: ok 1450 Send: N1452 G1 X-19.229 Y16.720 E114.14999*118 Recv: ok 1451 Send: N1453 G1 X-19.320 Y16.366 E114.16215*116 Recv: ok 1452 Send: N1454 G1 X-19.368 Y16.066 E114.17226*125 Recv: ok 1453 Send: N1455 G1 X-19.388 Y15.452 E114.19269*119 --- too many lines to buffer, cut off --- State: Error: Printer requested line 13598 but no sufficient history is available, can't resend File: Laser_blast_shield_1_0_a.gcode Timelapse: - Filament (Tool 0): 7.72m Approx. Total Print Time: 2 hours Print Time: 00:12:54 Print Time Left: 2 hours ● Printed: 420.3KB / 4.3MB [Laser_blast_shield_1_0_a.zip](https://github.com/guysoft/OctoPi/files/889580/Laser_blast_shield_1_0_a.zip) [Laser_blast_shield_1_0_a gcode.zip](https://github.com/guysoft/OctoPi/files/889582/Laser_blast_shield_1_0_a.gcode.zip) The stl is sliced with Cura externally and then the gcode is dropped onto octopi server page. Doug Vanderbilt Senior Trainer / Consultant Knowledge Tree Consulting cell: 404.630.9840 <(404)%20630-9840>

…

On Apr 3, 2017 4:50 AM, "Gina Häußge" ***@***.***> wrote: @dbvandy <https://github.com/dbvandy> What kind of mouse and keyboard and what kind of printer? I have not seen this behaviour in my own tests. Power issue? What does "Print jobs crash" mean, what happens exactly? @guysoft <https://github.com/guysoft> #336 <#336> at least sounds like we need some kind of workaround for the current raspi-config behaviour, otherwise IMHO no-go. Will comment there. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#332 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZmmWnjc2Cq6ysHKPet6AGGmLAIUjgqWks5rsLLggaJpZM4Mv453> .

[foosel]

Looks like some serious communication issues causing the stuttering, printer keeps requesting lines that look like they are sent ok. So either they become garbage on the line or when they arrive at the printer. So probably less of a CPU issue and more of a power issue (make sure the power supply provides 5V, 2.5A), or an overloaded bus maybe. Considering it's a wireless mouse, I wouldn't be too surprised actually if it's power and the dongle of the mouse is demanding too much, causing brown outs. Try leaving the mouse out of the equation. Currently running a test print against the image on a ZeroW, have a wireless keyboard-mouse-combo AND a mouse connected, as well as a pi camera and the printer itself. No communication errors. Power supply is this one, 5V, 2.5A.

I am not aware of a way to monitor the cpu processes on the pi

I'd recommend top, it's is already installed.

---

Side note: I'm still seeing the abysmal performance with regards to CPU load when the webcam tab is opened as already mentioned in #318. @guysoft Should we maybe add a "but not recommended" to the bit about support for the Zero W? I really have a bad feeling recommending this thing for running prints when the built-in wifi is used. Even a timelapse download could nuke prints with this kind of performance. Currently seeing 25% for kworker and 18% for irq/86-mmc1 (wifi handling) with traffic, and THAT certainly will cause stuttering.

[John-Mc]

I hope Guysoft's question "Is that a no-go for the feature?" #336 does not result in removal of the octopi-wpa-supplicant.txt feature. That feature is a major plus for those of us who need a pi to run on multiple networks and need to add new networks easily.

[foosel]

If we can't find a solution for the raspi-config issue though we'll at least need a big fat disclaimer in that file or we'll never hear the end of this issue (endless stream of tickets).

[foosel]

Considering this and

OctoPi version    : 0.14.0
------------------------------------------------------------------------------

pi@octopi:~ $ uname -a
Linux octopi 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux

I guess we should also make sure that RC2 has a newer kernel - if one is available.

[guysoft]

Is there a way to check if one is available?

[foosel]

https://www.raspberrypi.org/documentation/linux/kernel/updating.md

Tried both, official package is still <4.5, what you get via rpi-update is 4.9 but not recommended according to the link above.

Let's see what will be the state after the weekend.

[foosel]

New image is out, short summary of findings:

• kernel still at 4.4.50 from Feb 20 but taking a look at the 4.4.y branch on raspberrypi/linux it looks like the above CVE should be fixed in that one after all
• raspi-config still the old version without the fix by @kennethjiang mentioned in raspi-config breaks octopi-wpa-supplicant.txt link to wpa_supplicant.conf #336, so we still need the workaround provided in Service file to fix symlink for wpa_supplicant.conf #337
• libpam-chksshpwd no longer missing, meaning users logging in via SSH and locally will see a warning about changing their password if they haven't changed it from the default raspberry

I suggest building RC2 against that new image.

[guysoft]

@foosel Nighties are back, with the new image:

https://storage.googleapis.com/octoprint/2017-04-22_2017-04-10-octopi-jessie-lite-0.14.0.zip
MD5 - 0bb3aa2033e09fb0e59764fdb57f9d8b

Should we make RC2 out of this?

[John-Mc]

When RC2 comes out, is it possible to update to this from within OctoPrint, or do I need to start fresh from that image? (I do have my OctoPrint update channel set to Devel RC).

[guysoft]

@John-Mc Fresh image. You can move most of your OctoPrint preferences between images.