Jump to: navigation, search

Difference between revisions of "ReFactor"

(Created page with "= ReFactor = ReFactor is the next generation of controller board software stack installation. It is meant to simplify the lives of new users when they begin using a Thing-Pr...")
 
(ReFactor)
Line 13: Line 13:
 
# The ReFactor repository can be updated from the git repository and Ansible will only change what has been updated from the previous version, not needing a complete reinstallation of the system for upgrades.
 
# The ReFactor repository can be updated from the git repository and Ansible will only change what has been updated from the previous version, not needing a complete reinstallation of the system for upgrades.
 
# Description of components is modular, making it easy to pick and choose different components for the end goal desired, while keeping each component's setup independent and reliable, and independently updatable.
 
# Description of components is modular, making it easy to pick and choose different components for the end goal desired, while keeping each component's setup independent and reliable, and independently updatable.
 +
 +
== Building a flashable image for Replicape ==
 +
 +
The [[Replicape_B3]] runs on a Beaglebone black (or green, without video output), which has a single core ARM processor running at 1GHz with 512MB of RAM. While impressive for an embedded application, it's rather weak when trying to build a system, which can take a lot of time.
 +
 +
There's a significant time gain when building the image from a more powerful host system, then flashing it to memory from an SD card.
 +
 +
The host system can be any ARM v7 or above architecture machine. In this example, the Raspberry Pi 4 will be used as an example, as it has a quad-core 1.5GHz processor with 1 to 4GB of RAM. Any standard linux platform will do, but you will need a build storage space of at least 5GB for the build to succeed. Using a fast SD or a USB3 flash drive can provide higher disk speeds, reducing build time significantly.
 +
 +
To build an image from ReFactor for the Replicape, follow these steps:
 +
# Browse to a folder on the pi where you wish to run the build
 +
# Clone the [https://github.com/goeland86/ReFactor git repository] for ReFactor
 +
# In the ReFactor folder, run the build-image-in-chroot-end-to-end.sh script. It may take some time, so you may want to consider using a screen or byobu session to protect against network drops if you're doing so through SSH.
 +
# If the build completes successfully, you should be left with a file 'Umikaze-console.img.xz'
 +
# Use etcher to write the .img.xz file to a micro SD card, insert it into the Beaglebone, power it up and wait for it to power down.
 +
# Start using the ReFactor image on your printer
 +
 +
 +
The ultimate goal is to have multiple decliations of ReFactor, providing the user the ability to choose which firmware/software stack to run on their hardware. The following pre-build declinations are planned:
 +
* OctoPrint, Klipper, Toggle
 +
* OctoPrint, Redeem, Toggle
 +
* Duet Web Control, Klipper
 +
* Duet Web Control, Redeem
 +
 +
Only the first has been implemented so far, while the others are undergoing construction in the order shown in this list.
 +
The ReFactor images with OctoPrint are meant to provide drop-in replacements for the previous Umikaze images, including all the extra goodies that were present.
 +
 +
The default login is root with password kamikaze. The system will prompt for an immediate password change, to prevent a massive IoT exploitation through the web. Wouldn't want your printer sending out spam or starting to print unauthorized objects, now would we?
 +
 +
== Installing a custom software stack with ReFactor from a base Debian image ==
 +
 +
At the moment ReFactor only supports using a debian-based distribution as a basis. Further down the line it will be refactored so that many more packaging systems are supported - this is not an Ansible limitation, but rather simply a developer time limitation.
 +
 +
The goal for ReFactor is to allow the end-user to choose a custom software stack, while making installation of those packages easier. In this case, the user will want to learn how to write a simple Ansible playbook - there are multiple examples available in the ReFactor base folder (build_full_klipper_octoprint.yml, install_klipper.yml, any yml file really).
 +
 +
The files starting with "build_full_" are meant to be used for the image building described in the previous section. The files starting with "install_" are designed to be run on a printer platform exclusively - not on a host system.
 +
 +
Each install_ file will install a specific component with its required dependencies. For instance, if you with install toggle, it will also install the Beaglebone's graphics drivers, required for video output, along with a number of libraries that Toggle is reliant on (such as a custom-built libclutter using the framebuffer output instead of the X11 driver).
 +
 +
To install a specific component, make sure that you have installed ansible. Alternatively you can just run the prep_ubuntu.sh script - the only thing it does is make sure that Ansible is ready to execute any further tasks required.
 +
 +
Once Ansible is installed, just run "ansible-playbook install_klipper.yml" for example. Let it run and it will go through to make sure everything is available upon the next reboot.
 +
 +
After all packages have been installed as desired, reboot the system. A reboot is necessary, as depending on the software installed, kernel modules may be enabled / disabled, kernel versions may have changed etc. These are unfortunately not changes that can be done without a reboot.

Revision as of 12:34, 2 January 2020

ReFactor

ReFactor is the next generation of controller board software stack installation.

It is meant to simplify the lives of new users when they begin using a Thing-Printer controller board. Pre-built images of Ubuntu with ReFactor having run on them are available for users with less time or inclination to start from scratch.

ReFactor is a collection of desired states of the system image to include a printer firmware, a firmware control interface and optional additions.

ReFactor uses Ansible as the underlying framework to describe the desired system state. There are many reasons for this:

  1. Ansible describes the system's end state, not individual actions to perform, so it is relatively easy to port across platforms (i.e. debian, arch, BSD...)
  2. The ReFactor repository can be updated from the git repository and Ansible will only change what has been updated from the previous version, not needing a complete reinstallation of the system for upgrades.
  3. Description of components is modular, making it easy to pick and choose different components for the end goal desired, while keeping each component's setup independent and reliable, and independently updatable.

Building a flashable image for Replicape

The Replicape_B3 runs on a Beaglebone black (or green, without video output), which has a single core ARM processor running at 1GHz with 512MB of RAM. While impressive for an embedded application, it's rather weak when trying to build a system, which can take a lot of time.

There's a significant time gain when building the image from a more powerful host system, then flashing it to memory from an SD card.

The host system can be any ARM v7 or above architecture machine. In this example, the Raspberry Pi 4 will be used as an example, as it has a quad-core 1.5GHz processor with 1 to 4GB of RAM. Any standard linux platform will do, but you will need a build storage space of at least 5GB for the build to succeed. Using a fast SD or a USB3 flash drive can provide higher disk speeds, reducing build time significantly.

To build an image from ReFactor for the Replicape, follow these steps:

  1. Browse to a folder on the pi where you wish to run the build
  2. Clone the git repository for ReFactor
  3. In the ReFactor folder, run the build-image-in-chroot-end-to-end.sh script. It may take some time, so you may want to consider using a screen or byobu session to protect against network drops if you're doing so through SSH.
  4. If the build completes successfully, you should be left with a file 'Umikaze-console.img.xz'
  5. Use etcher to write the .img.xz file to a micro SD card, insert it into the Beaglebone, power it up and wait for it to power down.
  6. Start using the ReFactor image on your printer


The ultimate goal is to have multiple decliations of ReFactor, providing the user the ability to choose which firmware/software stack to run on their hardware. The following pre-build declinations are planned:

  • OctoPrint, Klipper, Toggle
  • OctoPrint, Redeem, Toggle
  • Duet Web Control, Klipper
  • Duet Web Control, Redeem

Only the first has been implemented so far, while the others are undergoing construction in the order shown in this list. The ReFactor images with OctoPrint are meant to provide drop-in replacements for the previous Umikaze images, including all the extra goodies that were present.

The default login is root with password kamikaze. The system will prompt for an immediate password change, to prevent a massive IoT exploitation through the web. Wouldn't want your printer sending out spam or starting to print unauthorized objects, now would we?

Installing a custom software stack with ReFactor from a base Debian image

At the moment ReFactor only supports using a debian-based distribution as a basis. Further down the line it will be refactored so that many more packaging systems are supported - this is not an Ansible limitation, but rather simply a developer time limitation.

The goal for ReFactor is to allow the end-user to choose a custom software stack, while making installation of those packages easier. In this case, the user will want to learn how to write a simple Ansible playbook - there are multiple examples available in the ReFactor base folder (build_full_klipper_octoprint.yml, install_klipper.yml, any yml file really).

The files starting with "build_full_" are meant to be used for the image building described in the previous section. The files starting with "install_" are designed to be run on a printer platform exclusively - not on a host system.

Each install_ file will install a specific component with its required dependencies. For instance, if you with install toggle, it will also install the Beaglebone's graphics drivers, required for video output, along with a number of libraries that Toggle is reliant on (such as a custom-built libclutter using the framebuffer output instead of the X11 driver).

To install a specific component, make sure that you have installed ansible. Alternatively you can just run the prep_ubuntu.sh script - the only thing it does is make sure that Ansible is ready to execute any further tasks required.

Once Ansible is installed, just run "ansible-playbook install_klipper.yml" for example. Let it run and it will go through to make sure everything is available upon the next reboot.

After all packages have been installed as desired, reboot the system. A reboot is necessary, as depending on the software installed, kernel modules may be enabled / disabled, kernel versions may have changed etc. These are unfortunately not changes that can be done without a reboot.