Raspberry Pi-re több 3D nyomtatót is ráköthetünk, de egyszerre csak az egyiket tudjuk vezérelni, mert az OctoPrint egy időben csak egyhez tud csatlakozni. Ez így nem az igazi, hiszen jó lenne párhuzamosan használni a nyomtatókat, ha már többen vannak.
A megoldás az, hogy egy Raspberry Pi-n több példányban futtatjuk az OctoPrint-et. Minden példány külön-külön csatlakozik egy-egy nyomtatóhoz, így minden nyomtatót a hozzátartozó OctoPrint-en keresztül tudunk vezérelni. Egymástól teljesen függetlenül.
Ehhez a következő feladatokat kell megoldani:
- Másolatot kell készíteni az OctoPrint-ről és a példányokat megkülönböztetve elérhetővé kell tenni kívülről.
- Az USB portokat névvel kell ellátnunk, hogy garantálni tudjuk azt, hogy minden OctoPrint példány biztosan a hozzátartozó nyomtatóhoz kapcsolódjon.
- Amennyiben csatlakoztattunk korábban más programokat az OctoPrint-hez az új elérhetőségeket át kell vezetnünk.
A példában az OctoPrint telepítésénél leírtak szerinti OctoPi image-ből készült OctoPrint-et fogom duplikálni. A következőkben ismertetett lépések nekem működőképes eredményt szültek, de ha bármi észrevételed van a leírással kapcsolatban, azt kérlek hozzászólásban jelezd!
Előkészületek
A telepítésénél leírtak szerint Putty terminálon keresztül fogunk dolgozni. Mivel nem vagyok Linux mágus, így nulladik lépésként telepítettem a Midnight Commander-t, hogy jobban lássam mit is csinálok:
sudo apt-get update sudo apt-get install mc
A ‘sudo mc’ utasítással indíthatjuk el, így Midnight Commander-ből is lesz jogosultságunk szerkeszteni a jogosultságot igénylő fájlokat.
OctoPrint második példányának elkészítése
Fájlok másolása, módosítása
Másoljuk le a /home/pi/.octoprint könyvtárat octoprint2 néven:
cp -R /home/pi/.octoprint /home/pi/.octoprint2
Másoljuk le az /etc/default/octoprint konfigurációs fájlt szintén octoprint2 néven:
sudo cp /etc/default/octoprint /etc/default/octoprint2
Módosítsuk a fájl-ban a port-ot és adjunk meg új basedir argumentumot. Ehhez vagy MC-vel tallózuk ki, vagy közvetlenül például így:
sudo nano /etc/default/octoprint2
Ezek legyenek az új értékek:
PORT=5001 DAEMON_ARGS="--host=$HOST --port=$PORT --basedir /home/pi/.octoprint2/"
Másoljuk le az init szkriptet és módosítsuk kicsit:
sudo cp /etc/init.d/octoprint /etc/init.d/octoprint2 sudo nano /etc/init.d/octoprint2
A fájl elején az összes ‘octoprint’-et javítsuk ‘octoprint2’ -re és hasonlóan az ‘OctoPrint’-et ‘OctoPrint2’-re. Kivéve az ‘DEAMON=/usr/bin/octoprint’ sort, ezt ne javítsuk át! A saját fájlom javított része így néz ki:
#!/bin/sh ### BEGIN INIT INFO # Provides: octoprint2 # Required-Start: $local_fs networking # Required-Stop: # Should-Start: # Should-Stop: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: OctoPrint2 daemon # Description: Starts the OctoPrint daemon with the user specified in # /etc/default/octoprint2. ### END INIT INFO # Author: Sami Olmari PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin DESC="OctoPrint2 Daemon" NAME="OctoPrint2" DAEMON=/usr/bin/octoprint PIDFILE=/var/run/$NAME.pid PKGNAME=octoprint2 SCRIPTNAME=/etc/init.d/$PKGNAME ...
Szolgáltatás beállítása
Mivel készítettünk egy új init szkriptet frissítsük a deamon-ok listáját:
sudo systemctl daemon-reload
Beállítjuk, hogy automatikusan induljon el bekapcsolás után:
sudo update-rc.d octoprint2 defaults
Most viszont indítsuk el kézzel és nézzük meg a státuszát:
sudo /etc/init.d/octoprint2 start systemctl status octoprint2.service
Ha azt látjuk, hogy active (running), akkor nagyon ügyesek voltunk, eddig minden rendben van. 🙂
Elvileg most már elérhető lenne a két különböző példány az 5000-es és az 5001-es porton. Viszont az OctoPi image belső proxy-val konfigurálva lett megcsinálva, így ezen a ponton nem vacakoltam a portok külső elérésével, hanem folytattam a példányok proxy beállításaival.
HaProxy beállítása
Érdemes két szép nevet választanunk a két példánynak, hogy egyértelműen meg tudjuk különböztetni őket. Ha két különböző típusú 3D nyomtatót használunk, akkor kézenfekvő a típusok nevét választani. Mivel én két HyperCube nyomtatót kötöttem egy raspberry-re, így bajban voltam hogyan jegyezzem meg a fantázianeveket. Egy szembetűnő különbség van köztük, az egyiken BLTouch szenzor van, a másikon pedig Proximity, így ezeket választottam elnevezésnek.
Arra megy ki a játék, hogy a két OctoPrint példányt ezeken a címeken érjük el:
- http://octopi.local/Proximity/
- http://octopi.local/BLTouch/
A HaProxy fog arról gondoskodni, hogy a kintről érkező többféle kérést (frontend) átirányítsa a megfelelő OctoPrint példányoknak (backend-ek).
Ehhez a /etc/haproxy.cfg fájlt kell módosítanunk, de mielőtt végzetesen tönkretesszük, készítsünk egy biztonsági másolatot róla:
sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.old
Ide másolom a módosított fájlt. Azt kell látni benne, hogy a frontend részben összepárosítjuk az URL-ben szereplő útvonal nevet a lejjebb konfigurálandó backend konfigurációk nevével. A deafult backend-et pedig a webkamerára módosítjuk. A korábbi egy octoprint backend helyett pedig elkészítjük a két újat a különböző elnevezésekkel a két különböző port-hoz.
global
maxconn 4096
user haproxy
group haproxy
log 127.0.0.1 local1 debug
defaults
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
option http-server-close
option forwardfor
maxconn 2000
timeout connect 5s
timeout client 15min
timeout server 15min
frontend public
bind :::80 v4v6
bind :::443 v4v6 ssl crt /etc/ssl/snakeoil.pem
option forwardfor except 127.0.0.1
use_backend webcam if { path_beg /webcam/ }
use_backend Proximity if { path_beg /Proximity/ }
use_backend BLTouch if { path_beg /BLTouch/ }
default_backend webcam
backend BLTouch
reqrep ^([^\ :]*)\ /BLTouch/(.*) \1\ /\2
option forwardfor
server octoprint1 127.0.0.1:5000
acl needs_scheme req.hdr_cnt(X-Scheme) eq 0
reqadd X-Scheme:\ https if needs_scheme { ssl_fc }
reqadd X-Scheme:\ http if needs_scheme !{ ssl_fc }
reqadd X-Script-Name:\ /BLTouch
errorfile 503 /etc/haproxy/errors/503-no-octoprint.http
backend Proximity
reqrep ^([^\ :]*)\ /Proximity/(.*) \1\ /\2
option forwardfor
server octoprint1 127.0.0.1:5001
acl needs_scheme req.hdr_cnt(X-Scheme) eq 0
reqadd X-Scheme:\ https if needs_scheme { ssl_fc }
reqadd X-Scheme:\ http if needs_scheme !{ ssl_fc }
reqadd X-Script-Name:\ /Proximity
errorfile 503 /etc/haproxy/errors/503-no-octoprint.http
backend webcam
reqrep ^([^\ :]*)\ /webcam/(.*) \1\ /\2
server webcam1 127.0.0.1:8080
errorfile 503 /etc/haproxy/errors/503-no-webcam.http
Ha helyesen készítettük el ezt a konfigurációs fájlt, akkor az octopi.local címre a webkamera képe jelenik meg, míg a két bekonfigurált OctoPrint példány a
octopi.local/Proximity/ és a octopi.local/BLTouch/ címeken érhető el.
De mielőtt elkezdenénk „kusztomizálni” a példányokat, még az USB portokat egyedivé kell tennünk.
Udev szabályok létrehozása az USB portokhoz
Bekapcsolás után véletlenszerű, hogy melyik nyomtató kerül az usb0 és usb1 portra, nekünk viszont fontos, hogy az OctoPrint példányok mindig a hozzájuk tartozó 3D nyomtatóhoz kapcsolódjanak. Ehhez szimbolikus linkeket hozzunk létre.
A szabályok létrehozásához valami különbséget kell tudnunk megragadni a csatlakoztatott nyomtatók között. Kérjük le mindkét USB csatlakozás információit és mentsük őket egy-egy fájlba:
udevadm info -a -n /dev/ttyUSB0 > devInfoUSB0 udevadm info -a -n /dev/ttyUSB1 > devInfoUSB1
A két fájl tartalmát vessük össze a diff paranccsal.
diff -u devInfoUSB0 devInfoUSB1
Olyan különbséget kell keresni, ami nem függ portok csatlakozásának sorrendjétől. A serial-t és a devpath-t láttam például ilyennek:
- ATTRS{serial}=="AH061HPY"
+ ATTRS{serial}=="AI02LL4K"
- ATTRS{devpath}=="1.4"
+ ATTRS{devpath}=="1.5"
Ezek alapján hozzuk létre a szabályokat:
sudo nano /etc/udev/rules.d/99-usb.rules
Nekem az alábbi két sorral működnek a hivatkozások, neked is valami hasonlót kell beállítanod, de persze azokkal az értékekkel amiket az udevadm info-val lekérdezve látsz. Legalább egy paraméterben különbözniük kell a soroknak. Az utolsó paraméterként megadott névvel hivatkozunk majd a portra.
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="AI02LL4K", SYMLINK+="ttyBLTouch"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="AH061HPY", SYMLINK+="ttyProximity"
Webkamerák beállítása
Egyelőre nincs két webkamerám, így ezt a lépést nem tudtam megcsinálni. A jövőben viszont lehet pótolom majd ezt a részt is. Hasonlóan a 3D nyomtatók portjainak elnevezéséhez, itt is a kamerák megkülönböztetéséről kell gondoskodnunk. A cikk végén, a forrásmegjelölésnél hivatkozott leírásban, ehhez is hasonlóan részletes leírást találsz.
OctoPrint webes felületek testreszabása
Jó hírem van, a terminálképernyőn gépelgetésnek vége! 🙂 Indítsuk újra az egész rendszert, majd kezdjük el beállítgatni a webes felületeket. A címeket a HaProxy beállításnál határoztuk meg, az egyik nálam például az http://octopi.local/Proximity/ címen érhető el. A settings menüben a Serial Connection alatt adjuk meg a megfelelő névvel ellátott USB csatlakozást az Additional serial port mezőben:
/dev/ttyProximity
Ezután állítsuk be a főképernyőn ezt a portot és állítsuk be, hogy automatikusan ehhez csatlakozzon bekapcsolás utána:
Azért, hogy egyértelmű legyen melyik 3D nyomtatót vezéreljük éppen, állítsunk be egyedi színt a fejléc háttérehéz és adjunk meg egy nevet, amit szintén a fejlécben fogunk látni. Ezt a settings/Appearance menüpontban tehetjük meg:
Ugyanezt végezzük el a másik példánnyal is. Ezek után a böngésző két külön fülén párhuzamosan tudjuk vezérelni a két nyomtatót, ráadásul elég egyértelműen megkülönböztetve.
Cura-ban az új elérhetőségek beállítása
Ha két egyforma nyomtatónk van, mint nekem a két HyperCube, akkor is érdemes két külön nyomtatót definiálni a Cura-ban is, és mindegyikhez külön hozzákapcsolni egy-egy OctoPrint példányt. Így már szeleteléskor eldönthetjük, hogy melyik 3d nyomtatóra küldjük ki a gcode-ot nyomtatásra.
A Cura és OctoPrint összekapcsolását ismertető bejegyzésemben a hálózaton automatikusan elérhető OctoPrint példányhoz állítottam be az API kulcsot. Valamiért ez most nem működött, pedig a példányokat listázta a Cura, csak a kulcsot nem tudtam helyesen megadni. Lehet ez valami bug a Cura plugin aktuális verziójában.
Ezért most kivettem a pipát az Automatical discover local OctoPrint instance elől és az Add gombra kattintva kézzel állítottam be az elérhetőséget. Az Instance Name-hez is a Path-ban megadandó HaProxy-ban definiált nevet írtam és így meg tudtam adni az API Key-t.
Források
A beállításokat nagyrészt az alábbi cikk lépései szerint készítettem:
Ha videón szeretnéd áttekinteni a lépéseket, akkor itt egy szintén nagyon alapos ismertető: