Skip to content

Multi instance

Multiple instances of KlipperScreen

Dificulty: Advanced

This article describes different methods of adding remote desktop clients (VNC or Xserver-XSDL) that do not support installing KS directly. If your remote device runs GNU/Linux then you should install KlipperScreen directly, instead of the methods described below.

The instances will be independent of each other and not a mirror.

Notes on Performance

Beware that running multiple instances on the same device at the same time will consume more resources (memory and processing time) and can be taxing on lower end hardware, in my testing even a Raspberry Pi 3A can run multiple instances of KS, providing that it doesn't have any cameras or other advanced features.

Tip

You can view the system resource usage in the "System" panel of KlipperScreen or directly at the console with htop Beware that even if the load seems okay at idle, during a print heavy dynamic loads can push the device over the threshold and that may result in a Klipper error/failure, if it's running on the same device.

Performance will heavily depend on the devices used, if one of the devices is connected through the network, like for example a VNC client or Android Xserver-XSDL client, then the network will influence the response time of the interface.

Option 1: Using the startup script method

Advantage: relatively easy to setup

Disadvantage: starting or stopping the service will affect all the instances

The default KlipperScreen service will launch the script

nano $HOME/KlipperScreen/scripts/launch_KlipperScreen.sh

Example script:

#!/bin/bash
/usr/bin/xinit $KS_XCLIENT &
DISPLAY=192.168.18.147:0 $KS_XCLIENT -c $HOME/.config/KlipperScreen/tablet.cfg &
wait

In this example the script launches a local instance for a screen connected to the host then it launches a server for xserver-xsdl client that is running at the defined IP, notice that the second instance uses a configuration that is specific to itself.

Dont forget to restart the service to load the changes

sudo systemctl restart KlipperScreen

Option 2: Using a separate service

Advantage: stopping and starting the service will only affect the desired instance

Disadvantage: configuration and setup is more complex

Create a new service unit file

sudo nano /etc/systemd/system/KlipperScreen_tablet.service

Example of a service unit for an android tablet: (change the IP and username)

KlipperScreen_tablet.service
[Unit]
Description=KlipperScreen Tablet
StartLimitIntervalSec=0
After=systemd-user-sessions.service plymouth-quit-wait.service
ConditionPathExists=/dev/tty0
Wants=dbus.socket systemd-logind.service
After=dbus.socket systemd-logind.service
After=moonraker.service

[Service]
Type=simple
Restart=always
RestartSec=2
SupplementaryGroups=klipperscreen
# username
User=pi
WorkingDirectory=/home/pi/KlipperScreen
Environment="DISPLAY=192.168.18.147:0"
# Absolute paths are required, separate config is optional
ExecStart=/home/pi/.KlipperScreen-env/bin/python /home/pi/KlipperScreen/screen.py -c /home/pi/.config/KlipperScreen/tablet.cfg

[Install]
WantedBy=multi-user.target

Test your new service

sudo systemctl start KlipperScreen_tablet

Optional: After veryfing it works, make it load when the system starts

sudo systemctl enable KlipperScreen_tablet

if you made a mistake in the config you'll have to reload the service unit

sudo systemctl daemon-reload

Add the new service to moonraker so it can be started and stopped from the UI

nano $HOME/printer_data/moonraker.asvc
In the example above it was KlipperScreen_tablet. Beware that is case sensitive

So in this case it would look something like this:

moonraker.asvc
klipper_mcu
webcamd
MoonCord
KlipperScreen
KlipperScreen_tablet
moonraker-telegram-bot
moonraker-obico
sonar
crowsnest
octoeverywhere

Restart moonraker

sudo systemctl restart moonraker