Replicape users,
Happy new year!
As a belated Christmas gift, allow me to share the beta-release of our new image build system:
Please read the release notes carefully.
Feel free to ask questions here or in Slack!
Cheers,
Jon
3 Likes
Problem identified:
When updating the config or issuing a RESTART, Klipper frequently does not restart correctly and returns an mcu-related error. Config is usually not at fault, a system reboot without changing config file resolves this.
I am investigating the cause and will hopefully issue a corrective update soon.
1 Like
Problem 1 update:
jakep_82 on Slack documents the same mcu issue happening 6 months back on a “by the book” installation of Klipper on his replicape. It may be a Klipper bug rather than a ReFactor bug. Still investigating.
Problem 2 identified - fix available:
Mjpg-streamer not properly installed.
To fix:
cd /usr/src/Umikaze
apt-get update
git remote set-url origin https://github.com/goeland86/ReFactor.git
git pull
ansible-playbook install_mjpgstreamer.yml
systemctl start mjpg
Problem 3: Bug with Toggle not starting
Toggle’s service dependency depends on a service that no longer exists, hence it fails at boot. Works fine when restarted manually after startup.
To fix:
cd /usr/src/Umikaze/
git pull
cp roles/install_toggle/files/toggle.service /lib/systemd/system/toggle.service
systemctl daemon-reload
systemctl restart toggle
Problem 4: git pull permission denied on github
It seems in my rush to get the beta out the door I forgot to change the git repository’s URL to use the public HTTPS instead of the SSH key (which you obviously do not have) on the image.
To fix this, it’s a very simple change - it was also updated in the problem 2 fix instructions:
apt-get update
cd /usr/src/Umikaze
git remote set-url origin https://github.com/goeland86/ReFactor.git
1 Like
Problem 5: Klipper crashes when restarting
Thanks to manbehindthemadness on slack for finally giving me the missing clue as to why Klipper refuses to restart properly on the beta 1 image. It seems that klipper needs to run with a much higher priority on the system, to avoid timing errors.
To fix this issue, run:
apt-get update
cd /usr/src/Umikaze
git remote set-url origin https://github.com/goeland86/ReFactor.git
git checkout master
git pull
systemctl stop klipper
systemctl stop klipper_pru
ansible-playbook install_klipper.yml
Dear all,
There’s a new beta in town!
Please be aware of a few important changes on this beta2 compared to the previous ReFactor beta:
- Login is now debian : temppwd
- Has Octoprint 1.4.0 installed
- Klipper & Klipper PRU can be restarted with a single
sudo systemctl restart klip
Read the release notes attentively. Previous bugfixes no longer needed (except maybe for Problem 4 - to be confirmed)
Again, big thanks to @BlackStump on our Slack & Github for his work on the installation scripts that make things work reliably.
1 Like
Aaand, not that long later, Beta 3 is out:
Please use Beta 3 instead of Beta 2 - there are significant issues with Beta 2. Read the release notes on Github!
1 Like
Problem 1 in beta 3
Connman service is not enabled.
To fix this for next boot(s):
sudo systemctl enable connman
To fix for the currently running BBB (only needed once):
sudo systemctl start connman
Then you can connect with connmanctl as expected.
New beta image available for Replicape.
Please read the notes in detail on github!
1 Like
Beta 6
Known issue #1:
Z1 endstop acts as a power button. Z1 triggers → power goes off. Fix is actively being sought, has to do with GPIO mappings.
Beta 6 issue 1 fix
After flashing and booting, ssh in with root:kamikaze credentials, make sure internet is available then run:
cd /usr/src/ReFactor
git pull
ansible-playbook SYSTEM_klipper_octoprint-DEFAULT.yml --extra-vars '{"platform":"replicape","packaging":"apt"}'
Or, if internet isn’t reachable, you can edit /etc/systemd/logind.conf with nano change
#HandlePowerKey=shutdown to HandlePowerKey=ignore
Then run systemctl restart systemd-logind and you’re good to go.
RC3 image
Released RC3 image with a few additional fixes.
General changes
Fixes issues with RC2 regarding OctoPrint initial config file.
Switches from iptables to the newer nftables to stay consistent with the latest Debian buster documentation.
Installs OctoPrint in a Python 3.7 venv instead of Python2.7
Recore-specific
Updated the download link for the pine64 Debian buster image that serves as the base.
Replicape-specific
Changed base image from IoT image from beaglebone.org to console image from RCN. Eliminates a lot of unneeded packages to save on size.
1 Like
Problem in RC3
The OctoKlipper plugin in RC3 will not work. Using python3.7 for octoprint breaks compatibility with python2 plugins, of which OctoKlipper was not updated.
I will try to fork and update the plugin to work on python3, but I don’t yet have a solid timeline on that.
I see your comments at Python 3 · Issue #14 · Klipper3d/klipper · GitHub — I also see that no one has posted tests of gcode performance between Python 2.7 and python 3 later than 3.5 where he tested. Just assertions that 3.8 is faster than 3.5.
It might that posting equivalent or better performance from the tests Kevin posted in Python 3 · Issue #14 · Klipper3d/klipper · GitHub would be the most likely thing to move the needle for Klipper itself, which would possibly help motivate change for OctoKlipper — if both octoprint and Klipper support py3, maybe OctoKlipper will too.
time ~/klippy-env/bin/python ./klippy/klippy.py config/example.cfg -i test.gcode -o /dev/null -d out/klipper.dict
OctoKlipper was not written by Kevin - so while it would be great for Klipper to move to py3, it won’t move OctoKlipper any sooner.
At this stage, I’m happy to leave Klipper in py2, but we should make a py3-compatible fork of OctoKlipper. I’ve checked it out on my machine, but won’t have time this week to do anything with it yet.
Oh, I just thought if the whole rest of the ecosystem moved it would make it more likely. 
I’m not sure. I think the Klipper community as a whole is moving away from OctoPrint entirely. They’re building their own UI, and have had a plugin to use the Duet Web Control frontend for a while.
As far as I can tell, their own UI (Mainsail) is also still using python2.
Oh. Well, I’m on record as saying that the Python community really missed the mark on the Python 3 “migration”.
At the same time, I’m really curious whether Py3 is actually still slower over three Py3 major releases with additional speed improvements.
1 Like