Віртуальний принтер¶

Віртуальний принтер (VP) робить так, що BamDude з'являється у вашій LAN як один або кілька принтерів Bambu Lab. "Send to Printer" з Bambu Studio / OrcaSlicer лягає на VP так само, як він лягав би на справжній принтер — через захищений TLS (MQTT + FTPS) з access-кодом принтера. Далі BamDude роутить аплоад згідно з режимом VP.

Огляд¶

Кожен VP:

Анонсує себе через SSDP з реальним кодом моделі Bambu (X1C / P1S / A1 Mini / H2D / …), щоб слайсери виявляли його автоматично.
Запускає власні FTPS + MQTT + SSDP сервери на своєму Bind IP. Кожному одночасно увімкненому VP потрібна інша локальна IP, бо порти служб фіксовані. Якщо наявних адрес хоста недостатньо, додайте IP-аліаси.
Несе access-код, як справжній принтер — слайсери питають його при першому використанні і кешують потім.
Має серійний номер і код моделі, що збігаються з реальним форматом Bambu, — тож compatibility checks слайсера проходять.

Режими¶

VP працює в рівно одному режимі. Режим задається per-VP і валідується сервером — будь-що інше відхиляється з HTTP 400.

Режим	Що відбувається з аплоадами	Use case
`file_manager` (дефолт)	Аплоад зберігається в бібліотеку File Manager, і більше нічого не відбувається — ні друку, ні черги. Оператор друкує його звідти, коли буде готовий.	Multi-user / multi-machine inbox, де кожен аплоад спершу переглядають — також правильний режим, якщо ви хочете просто зберегти файл без друку.
`print_queue`	Аплоад архівується і ставиться в чергу на конкретний цільовий принтер. З `auto_dispatch=true` queue item стартує одразу; з `auto_dispatch=false` чекає на explicit Start-клік.	Аплоади з цього VP завжди їдуть на ту саму машину.
`auto_queue`	Файл зберігається в бібліотеці й після перевірки плити потрапляє в авточергу. Машина обирається за точною моделлю та повним набором вимог до філаменту, подачі й сопел. Force colour match вимагає кольорів кожного використаного каналу.	Розподіл між принтерами ферми.
`proxy`	TLS-сесія слайсера TCP-проксується на реальний `target_printer_id` — BamDude лише публічний endpoint.	Віддалений друк — слайсер достукується до BamDude через LAN/VPN, BamDude достукується до принтера.

Окремого режиму ‘тільки архівувати’ немає

Раніше ця сторінка згадувала режим immediate, який нібито автоматично створює archive-рядок без черги і бібліотеки. Такого режиму в коді не було ніколи — документація брехала. Mode-енум у коді — це рівно чотири варіанти вище (див. backend/app/models/virtual_printer.py та валідатор у backend/app/api/routes/virtual_printers.py). Щоб отримати "тільки архівувати", використовуйте file_manager + bulk-archive у review-модалці — це створить рядок у print_archives і навіть не зачепить принтер.

Дзеркалення живого стану в non-proxy режимах¶

Коли non-proxy VP (file_manager / print_queue / auto_queue) налаштований з target-принтером, слайсер, який говорить з VP, бачить реальний живий стан принтера — не заморожену idle-заглушку. Детект слотів AMS, FTS-роутинг, ідентифікація типу сопла, k-profiles на філамент і жива камера працюють так, ніби слайсер говорить безпосередньо з принтером. Ви зберігаєте чергу / архів / диспетчеризацію BamDude і отримуєте slicer-as-remote-ергономіку у тому ж VP.

Як це працює (важливе для оператора):

BamDude вже тримає per-printer MQTT-підписку — другої сесії на принтері не відкриваємо, бюджет in-flight повідомлень фірмварі не страждає.
VP кешує останні push_status і info.get_version від принтера й віддає слайсеру майже байт-у-байт ідентичну копію реального push'а. Перевизначаємо лише upload-state-поля, якими керує BamDude (gcode_state, gcode_file, prepare_percent, subtask_name).
Device-таб слайсера показує живий прогрес друку target-принтера — поточну стадію, відсоток, шар і час до кінця, тож за роботою можна стежити з того ж слайсера, з якого ви її відправили. Кнопка Send лишається активною весь час, тож можна ставити наступну роботу в чергу, поки друкується поточна. Чому для цього потрібен маленький обман — у примітці нижче.
Slicer-команди (AMS load / unload, xcam, extrusion_cali_get для k-profile, …) форвардяться на реальний принтер. project_file / gcode_file все одно завершуються локально — файл лежить у BamDude.
Камера — raw TCP passthrough на <bind_ip>:322 → printer:322 (той самий підхід, що в proxy-режимі).

Однаковий access code на VP і target-принтері

BambuStudio автентифікує RTSPS access-кодом зі свого профілю слайсера — VP і його target мають мати однаковий access code, інакше кнопка камери впаде з "LAN connection failed". MQTT і FTPS працюють обома способами. Виставте через Settings → Virtual Printer → Edit і Settings → Printers → Edit.

Чому слайсер пише «Finished», показуючи при цьому прогрес

Bambu Studio і OrcaSlicer гейтять і панель прогресу в Device-табі, і кнопку Send на одній і тій самій внутрішній перевірці — «цей принтер зараз друкує?». Віддати реальний стан принтера як є означало б показати прогрес ціною сірої кнопки Send на весь час друку — а це вбиває сенс non-proxy VP.

Finished — єдиний стан, який малює панель прогресу і водночас лишає Send живим, тож VP віддає саме його, а під ним — справжні цифри. Тому слово-статус у слайсері під час дзеркаленого друку нічого не означає: дивіться на відсоток, шар і час, або на картку принтера в BamDude.

Дзеркало навмисно паузиться у двох випадках: поки передається ваш власний аплоад (і кілька секунд після, щоб не збити рукостискання відправки), і коли target-принтер насправді не друкує. Помилки принтера теж ніколи не дзеркаляться — несправність підняла б у слайсері модальне вікно, а VP не та машина, що її кинула, тож BamDude показує її на картці принтера.

Proxy-режим це не зачепило

Proxy-режим тримає власні RTSP / FTP / MQTT проксі і роутить усе end-to-end на TCP-рівні — кешу немає чого дзеркалити. Поведінка вище — opt-in для трьох non-proxy режимів.

Налаштування¶

Налаштування → Virtual Printer → Add Virtual Printer:

Поле	Примітки
Name	Display-лейбл (наприклад, `Studio inbox`).
Model	SSDP model code — оберіть модель принтера, яку VP має імперсонувати, щоб compatibility checks слайсера проходили.
Bind IP	Обов'язкове для увімкнення VP. Локальна IP, призначена комп'ютеру з BamDude та доступна слайсеру. Кожному увімкненому VP потрібна інша IP. Запис адреси в це поле не додає її у Windows/Linux: спочатку налаштуйте адресу за інструкцією нижче.
Access code	8-символьний код, яким автентифікується слайсер.
Mode	Один з чотирьох вище.
Auto-dispatch	Активний у режимах `print_queue` і `auto_queue` — див. нижче.
Target printer	Тільки для режиму `print_queue` (конкретний таргет) і `proxy`. Прихований коли вибрано `auto_queue` або `file_manager`.

Слайсери виявляють новий VP через SSDP автоматично за хвилину-дві. Якщо discovery не спрацював, додайте вручну за IP + access-кодом.

Потрібні порти¶

Зазвичай ручного налаштування не треба

Контейнер / нативна інсталяція відкриває потрібні порти автоматично — таблиця нижче для довідки: фаєрвол, Docker NAT, мульти-NIC, proxy mode.

Кожен VP використовує ці порти на своєму bind IP:

Сервіс	Порт	Протокол	Призначення
Bind / detect	3000, 3002	TCP	Хендшейк "Add Printer" слайсера — потрібен у всіх режимах
SSDP	2021	UDP	Авто-discovery в LAN (не працює через VPN / Docker bridge / remote)
MQTT	8883	TCP/TLS	Контроль + статус принтера
File transfer tunnel	6000	TCP/TLS	Verify-job + завантаження файлу (proxy mode + камера A1/P1)
RTSP camera	322	TCP/TLS	Стрім камери X1 / H2 / P2 — proxy mode і не-proxy режими, коли заданий target printer (через цей порт йде live-камера слайсера)
FTPS	990	TCP/TLS	Контроль FTP
FTP PASV data	10-портовий слайс на VP у межах `50000–50999`	TCP	Пасивний канал даних FTP — кожен non-proxy VP має свій слайс (VP 1 → `50000–50009`, VP 2 → `50010–50019`, …); proxy-режим натомість форвардить діапазон таргет-принтера
Slicer proprietary	2024–2026	TCP/TLS	Протокол слайсер ↔ принтер для A1 / P1S (proxy mode)

Чому два bind-порти

Різні версії Bambu Studio і OrcaSlicer використовують різні порти для bind-хендшейку. BamDude слухає обидва — 3000 і 3002 — щоб будь-який слайсер сконектився.

Привілейований порт 990

На Linux порт 990 привілейований (<1024). Процесу потрібен CAP_NET_BIND_SERVICE або root для bind. Готовий Docker-образ і systemd unit вже мають цю capability. Ця вимога Linux не стосується нативної Windows.

Пасивні FTP-порти нарізаються на кожен VP

Кожен non-proxy VP отримує власний 10-портовий слайс пасивних даних, виділений із його database id: VP 1 → 50000–50009, VP 2 → 50010–50019 і так далі (слот вертається після 100 VP, тож будь-який слайс лишається в межах 50000–50999). Це замінило старий плаский пул 50000–50100 — під дефолтним userland-проксі Docker'а той широкий діапазон породжував ~2000 host-процесів (~3.5 GB host RAM). Відкривай лише ті слайси, які твої VP реально використовують, і додавай по 10 портів на кожен наступний VP. Точний слайс запущеного VP видно в його стартовому лозі FTP passive data port range: <min>-<max>. Proxy-режим — виняток: він форвардить повний пасивний діапазон таргет-принтера (приблизно 50000–50100).

Додаємо VP у слайсер¶

Авто-discovery (та сама LAN)¶

VP увімкнений (Settings → Virtual Printer → toggle on, статус Running).
У Bambu Studio / OrcaSlicer відкрий Device → Refresh (або зачекай — він поллить).
VP зʼявляється у списку пристроїв як модель, яку ти обрав. Вибери, встав access code — все.

Ручне додавання (VPN / Docker bridge / remote / інша підмережа)¶

SSDP — link-local: бродкасти не виходять за роутер, через VPN tun, ні через Docker bridge. Тоді:

Device → Add Printer → Add printer manually (або "Bind with access code" — залежить від білда слайсера).
IP: досяжний IP хоста BamDude (або per-VP bind IP, якщо ти його задав).
Access code: 8-символьний код з картки VP.

Bind-порти повинні бути досяжні

Хендшейк іде на 3000 або 3002 — машина зі слайсером має могти TCP-конектитись на цей порт хоста BamDude. Фаєрвол, port forwarding, Docker ports: — будь-що з цього може ламати.

Відправка прінтів — Send vs Print¶

Тиснемо Send, а не Print

Send → шле 3MF в BamDude, далі по режиму VP (review / queue / auto-queue / archive). Правильно.
Print → каже слайсеру стартанути друк негайно на справжньому принтері. VP — не принтер, тому або таймаут, або помилка.

У Bambu Studio / OrcaSlicer кнопка Send стоїть біля Print (або під випадайкою на кнопці Print — залежить від версії слайсера). Що буде далі — залежить від режиму VP.

Для VP у режимі proxy тиснемо Print як завжди — proxy режим прозорий, він форвардить на справжній принтер.

Multi-plate 'Send all plates'

Коли використовуєш Send all plates слайсера на multi-plate 3MF у VP режиму черги, BamDude ставить у чергу по одному айтему на плейт у порядку плейтів — а не один айтем на весь файл — тож планувальник виконує кожен плейт як окремий джоб. Одноплейтний Send лишається одним айтемом.

Встановлення сертифікату¶

VP піднімає MQTT + FTPS + RTSP за самопідписаним CA, який BamDude генерує під час першого вмикання VP. Bambu Studio і OrcaSlicer його з коробки не довіряють — у них захардкожений список CA Bambu, і (на macOS / Windows) системний trust store ігнорується. Треба додати CA BamDude у файл printer.cer, який лежить у слайсера (на Linux — варіант ще через системний CA store, якщо твій білд його поважає).

Коли треба повторити

Перший раз (на кожній новій інсталяції)
Перенесли BamDude на новий хост (кожна інсталяція генерить свій унікальний CA — крім випадку, коли ти переніс директорію certs/)
Слайсер оновився і затер printer.cer (часто на Windows / macOS)

Крок 1 — Знаходимо CA BamDude¶

CA лежить у <DATA_DIR>/virtual_printer/certs/bbl_ca.crt.

NativeDocker

# за замовчуванням DATA_DIR — це ./data поряд з інсталяцією
cat data/virtual_printer/certs/bbl_ca.crt

docker cp bamdude:/app/data/virtual_printer/certs/bbl_ca.crt ./bamdude-ca.crt

CA генерується ліниво

bbl_ca.crt зʼявляється тільки після того, як ти увімкнув VP перший раз. Якщо файлу нема — створи + увімкни VP в UI, потім ще раз cp.

Крок 2 — Дописуємо CA у `printer.cer` слайсера¶

printer.cer — PEM-бандл CA, яким слайсер довіряє для підключень до принтерів. Відкрий, допиши CA BamDude в самому кінці (після останнього -----END CERTIFICATE-----), збережи, потім повністю перезапусти слайсер (Cmd+Q на macOS — закрити вікно недостатньо; Task Manager → End Task на Windows).

Дописуємо, не замінюємо

Дописуючи, ти зберігаєш довіру до справжніх принтерів Bambu Lab. Заміна файлу ламає Bambu Cloud / прямий MQTT до фізичного заліза.

Де живе printer.cer:

macOSWindowsLinux — .deb / .rpmLinux — AppImage

Bambu Studio: /Applications/BambuStudio.app/Contents/Resources/cert/printer.cer
OrcaSlicer: /Applications/OrcaSlicer.app/Contents/Resources/cert/printer.cer

Bambu Studio: C:\Program Files\Bambu Studio\resources\cert\printer.cer
OrcaSlicer: C:\Program Files\OrcaSlicer\resources\cert\printer.cer

Нативні пакети лінкуються з системним OpenSSL і підхоплюють системний CA bundle, коли в ~/.config/BambuStudio/BambuStudio.conf стоїть tls_cert_store_accepted: yes (default після першого запуску). Тоді ставимо CA системно:

Debian / Ubuntu / Mint / Raspberry Pi OS:

sudo cp bbl_ca.crt /usr/local/share/ca-certificates/bamdude-ca.crt   # розширення ОБОВʼЯЗКОВО .crt
sudo update-ca-certificates

Fedora / RHEL / openSUSE:

sudo cp bbl_ca.crt /etc/pki/ca-trust/source/anchors/bamdude-ca.crt
sudo update-ca-trust

Arch:

sudo trust anchor --store bbl_ca.crt

Потім повністю перезапусти слайсер.

Поширена помилка

Кинути файл у /etc/ssl/certs/ і запустити update-ca-certificates — no-op. Інструмент бере тільки файли з /usr/local/share/ca-certificates/ із розширенням .crt.

Якщо системний store не береться — фолбек у пряме редагування (вони root-owned, тож sudo):

Bambu Studio: /usr/share/Bambu Studio/resources/cert/printer.cer
OrcaSlicer: /usr/share/OrcaSlicer/resources/cert/printer.cer

Прямі правки скидаються при кожному оновленні пакета.

Системний CA store ненадійний для AppImage-білдів (вони мають свій мережевий стек). Розпаковуй, редагуй вшитий printer.cer, запускай з розпакованого дерева:

./Bambu_Studio_linux_*.AppImage --appimage-extract
# редагуй squashfs-root/usr/share/Bambu Studio/resources/cert/printer.cer
./squashfs-root/AppRun

Повторювати щоразу при оновленні AppImage.

Персистентність CA¶

CA генерується один раз і живе через рестарти BamDude. Тримай <DATA_DIR>/virtual_printer/certs/ у бекапі — без нього після наступного рестарту кожен слайсер доведеться переімпортувати на новий CA.

Якщо перемикаєшся між Docker і native і хочеш один CA на обидва — share-уй директорію через bind-mount:

volumes:
  - ./virtual_printer:/app/data/virtual_printer

Кілька хостів BamDude¶

Кожна інсталяція генерує свій CA. Два чисті варіанти:

Поділити CA (рекомендовано для ферм)

scp -r host1:/path/to/data/virtual_printer/certs/ host2:/path/to/data/virtual_printer/
# рестарт bamdude на host2

Усі хости тепер з одним CA — один сертифікат у слайсері покриває всіх.

Або: переімпорт на хост

При перемиканні слайсера на інший хост BamDude — видали старий блок CA з printer.cer, додай новий, повністю перезапусти слайсер.

Один CA BamDude за раз

Запхати кілька CA BamDude у printer.cer криптографічно ОК, але це робить дуже легко вказати слайсер на "не той" хост випадково. Чисти старі.

Виділені bind IP (кілька VP)¶

Кожному одночасно увімкненому VP потрібна власна локальна IP. Порти однакові й фіксовані, тому кілька VP не можуть ділити одну IP. IP-аліас — це додаткова адреса на наявному мережевому адаптері; ще одна фізична мережева карта не потрібна.

Один VP: можна використати основну LAN-адресу хоста, якщо потрібні порти вільні. Додатковий аліас не є безумовною вимогою, хоча окрема адреса VP спрощує супровід.
Кілька VP: забезпечте достатньо різних локальних IP, зазвичай по одному аліасу на VP. Наявні відповідні адреси інших адаптерів також підходять. Якщо адрес недостатньо, додаткові адреси потрібні для роботи, а не лише для продуктивності.
BamDude не створює аліаси. Вільної адреси в підмережі, резервації на роутері або запису в Bind IP недостатньо: ОС має реально володіти адресою до запуску VP. Вказуйте адресу VP, а не фізичного цільового принтера.

У Bind IP вказуйте конкретну локальну адресу. 0.0.0.0 означає всі інтерфейси, не є аліасом чи адресою для введення у слайсері та може конфліктувати з іншими VP. У контейнері адреса має належати його мережевому простору; дивіться вкладки платформ нижче.

Приклад розкладу:

	IP
BamDude UI	`192.168.1.100` (основний хоста)
VP 1	`192.168.1.101`
VP 2	`192.168.1.102`
VP 3	`192.168.1.103`

Бери вільні IP

Виключіть вибрані адреси з видачі DHCP та перевірте оренди/резервації роутера й перелік статичних адрес. Відповідь на ping означає, що адреса зайнята; відсутність відповіді не доводить, що вона вільна. Використовуйте правильну підмережу/префікс і адаптер, доступний слайсеру.

Додаємо аліаси інтерфейсу¶

Windows (нативна інсталяція/служба)Linux (native або Docker host mode)UnraidSynology NASTrueNAS SCALEProxmox LXCDocker Desktop (macOS / Windows)

Windows підтримує кілька IPv4-адрес на одному адаптері. Відкрийте PowerShell від адміністратора на ПК з BamDude. Ця інструкція для нативної Windows-інсталяції, а не контейнера Docker Desktop.

Перегляньте поточні налаштування:

Get-NetIPConfiguration
Get-NetIPInterface -AddressFamily IPv4 | Format-Table InterfaceIndex,InterfaceAlias,ConnectionState,Dhcp

Перевірте DHCP перед додаванням адреси

New-NetIPAddress вимикає DHCP на вибраному адаптері, якщо він увімкнений. Спочатку узгодьте з адміністратором мережі статичну основну IP, підмережу, шлюз і DNS; зміна через віддалений сеанс може його обірвати. DHCP-резервація на роутері не змінює режим адаптера. Приклад нижче відмовиться працювати на DHCP-адаптері.

Замініть індекс 12, IP та префікс значеннями своєї LAN. Збережіть основну адресу; додайте лише додаткову адресу VP:

$vpInterface = Get-NetIPInterface -InterfaceIndex 12 -AddressFamily IPv4 -ErrorAction Stop
if ($vpInterface.Dhcp -ne 'Disabled') {
    throw 'Спочатку налаштуйте статичну основну IPv4-адресу, шлюз і DNS, потім додавайте аліас VP.'
}
New-NetIPAddress -InterfaceIndex $vpInterface.InterfaceIndex -IPAddress 192.168.1.101 -PrefixLength 24 -SkipAsSource $true -ErrorAction Stop

Повторіть останню команду з .102, .103 тощо для інших VP. Не додавайте другий шлюз за замовчуванням. SkipAsSource виключає аліас з автоматичного вибору вихідної адреси та реєстрації у DNS. Якщо PolicyStore не вказаний, адреса зберігається після перезавантаження. Дивіться довідку команди Microsoft.

Перевірте, що кожен аліас отримав AddressState = Preferred (перевірка дублювання адреси може тривати певний час):

Get-NetIPAddress -InterfaceIndex 12 -AddressFamily IPv4 | Format-Table IPAddress,PrefixLength,AddressState,SkipAsSource

Вкажіть цю саму IP у Налаштування → Virtual Printer → Bind IP, увімкніть VP та дозвольте його потрібні вхідні порти у Windows Firewall для мережі слайсера. Перевірте статус роботи VP; команда Test-NetConnection 192.168.1.101 -Port 8883 на ПК зі слайсером перевіряє TCP-доступність, а не автентифікацію чи всі служби VP.

Щоб згодом прибрати аліас, спочатку вимкніть VP та видаліть лише додаткову адресу, зберігши основну IP:

Remove-NetIPAddress -InterfaceIndex 12 -IPAddress 192.168.1.101 -Confirm

Знайди імʼя інтерфейсу:

ip -br addr show
# eth0  UP  192.168.1.100/24

Додай аліаси (тимчасові — після ребута зникнуть):

sudo ip addr add 192.168.1.101/24 dev eth0
sudo ip addr add 192.168.1.102/24 dev eth0
sudo ip addr add 192.168.1.103/24 dev eth0

Робимо постійно:

Netplan (Ubuntu 18.04+, Debian 12+)/etc/network/interfaces (Debian, Raspberry Pi OS)NetworkManager (Fedora, RHEL, Arch)

У /etc/netplan/*.yaml:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      addresses:
        - 192.168.1.101/24
        - 192.168.1.102/24
        - 192.168.1.103/24

sudo netplan apply.

auto eth0:1
iface eth0:1 inet static
    address 192.168.1.101
    netmask 255.255.255.0

auto eth0:2
iface eth0:2 inet static
    address 192.168.1.102
    netmask 255.255.255.0

sudo ifup eth0:1 eth0:2.

sudo nmcli con mod "Wired connection 1" +ipv4.addresses "192.168.1.101/24"
sudo nmcli con mod "Wired connection 1" +ipv4.addresses "192.168.1.102/24"
sudo nmcli con up "Wired connection 1"

Імʼя зʼєднання — nmcli con show.

SSH або веб-термінал:

ip addr add 192.168.1.101/24 dev eth0
ip addr add 192.168.1.102/24 dev eth0

Постійно — у /boot/config/go:

echo "ip addr add 192.168.1.101/24 dev eth0" >> /boot/config/go
echo "ip addr add 192.168.1.102/24 dev eth0" >> /boot/config/go

SSH:

sudo ip addr add 192.168.1.101/24 dev eth0
sudo ip addr add 192.168.1.102/24 dev eth0

Постійно — Control Panel → Task Scheduler → Triggered Task → User-defined script, тригер Boot-up, користувач root, ті ж рядки ip addr add ….

Network → Interfaces → Edit → додай Aliases (192.168.1.101/24, …) → Save → Apply. Постійно автоматично.

Усередині контейнера — постав iproute2, далі Linux-інструкції вище (netplan або /etc/network/interfaces).

З Proxmox-хоста — /etc/pve/lxc/<CTID>.conf:

net0: name=eth0,bridge=vmbr0,ip=192.168.1.100/24,gw=192.168.1.1
net1: name=eth1,bridge=vmbr0,ip=192.168.1.101/24
net2: name=eth2,bridge=vmbr0,ip=192.168.1.102/24

Або pct set <CTID> -net1 name=eth1,bridge=vmbr0,ip=192.168.1.101/24. Перезапустити контейнер після.

Аліаси Windows не є адресами контейнера

Bridge-приклад на цій сторінці публікує один VP. Додавання аліасів у Windows не робить їх доступними для bind у контейнері. Docker Desktop 4.34+ має опціональний host networking, але він також не надає контейнеру прямого доступу до інтерфейсів та IP хоста. Для описаної схеми з кількома VP використовуйте нативну Windows або Linux / Linux Docker host networking. Дивіться обмеження Docker.

Docker host mode

У Linux Docker Engine з network_mode: host додавайте аліаси на Docker-хості, а не в контейнері: вони ділять мережевий простір. Це не опис host networking у Docker Desktop.

SSDP-коди моделей¶

VP видає себе за реальну модель Bambu, щоб слайсерська перевірка сумісності пройшла. Бери модель, що збігається з пресетом слайсера.

SSDP-код	Назва	Префікс серійника
`BL-P001`	X1C (default)	00M
`BL-P002`	X1	00M
`C13`	X1E	03W
`N6`	X2D	20P9
`N9`	A2L	26A19
`C11`	P1P	01S
`C12`	P1S	01P
`N7`	P2S	22E
`N2S`	A1	039
`N1`	A1 Mini	030
`O1D`	H2D	094
`O1E` / `O2D`	H2D Pro (експериментально — коди переписані з довідника моделей, ще не підтверджені на живому H2D Pro)	094
`O1C` / `O1C2`	H2C (O1C2 = dual-nozzle)	094
`O1S`	H2S	094

Зміна моделі рестартить VP

Зміна моделі регенерить серійник і рестартить слухачі. Слайсер побачить новий принтер — швидше за все доведеться додавати наново (кеш паринга у слайсера зашитий по серійнику).

Network Interface Override¶

Коли в хоста кілька NIC (Tailscale, кілька LAN-бриджів, Docker overlay, dual-homed routing), авто-detect IP BamDude може потрапити не на ту інтерфейсу — слайсери з потрібного сегмента не дотягуються, та й IP, який лягає в SAN сертифікату, не пройде перевірку.

Settings → Virtual Printer → Network Interface Override — обираємо, який інтерфейс BamDude:

анонсує в SSDP-discovery
зашиває в SAN TLS-сертифікату

Працює у всіх режимах (server modes + proxy SSDP relay). Бери інтерфейс, з якого слайсер реально дотягується до BamDude.

Tailscale¶

Tailscale — рекомендований шлях для віддаленого доступу слайсера: слайсер досягає VP через приватну WireGuard-мережу звідки завгодно, без port forwarding і без публічного експорту.

Тогл Tailscale на картці VP показує IP / MagicDNS-host у tailnet — це і вставляєш у слайсер. CA однаково треба імпортувати в слайсер (Tailscale не змінює довіру до сертифікатів).

Повний setup (native + Docker + LXC), prerequisites і troubleshooting — у виділеному гайді:

Tailscale-інтеграція

Платформенне налаштування¶

Відкрий порти зі списку вище у фаєрволі.

Linux nativeDocker (Linux, host mode)Docker Desktop (macOS / Windows)Unraid / Synology / TrueNAS SCALEProxmox LXC

Порту 990 потрібен CAP_NET_BIND_SERVICE. Готовий systemd unit вже містить:

AmbientCapabilities=CAP_NET_BIND_SERVICE

Для ручного запуску — capability на бінарь Python:

sudo setcap cap_net_bind_service=+ep $(readlink -f $(which python3))

UFW:

sudo ufw allow 3000/tcp
sudo ufw allow 3002/tcp
sudo ufw allow 2021/udp
sudo ufw allow 8883/tcp
sudo ufw allow 990/tcp
sudo ufw allow 6000/tcp
sudo ufw allow 322/tcp
sudo ufw allow 2024:2026/tcp
sudo ufw allow 50000:50009/tcp   # пасивний слайс одного VP; додай по 10 портів на кожен наступний VP (…:50019, …:50029, …)

firewalld:

sudo firewall-cmd --permanent --add-port=3000/tcp
sudo firewall-cmd --permanent --add-port=3002/tcp
sudo firewall-cmd --permanent --add-port=2021/udp
sudo firewall-cmd --permanent --add-port=8883/tcp
sudo firewall-cmd --permanent --add-port=990/tcp
sudo firewall-cmd --permanent --add-port=6000/tcp
sudo firewall-cmd --permanent --add-port=322/tcp
sudo firewall-cmd --permanent --add-port=2024-2026/tcp
sudo firewall-cmd --permanent --add-port=50000-50009/tcp   # пасивний слайс одного VP; +10 портів на кожен наступний VP
sudo firewall-cmd --reload

Host networking обовʼязкове для SSDP-discovery. Стандартний compose:

services:
  bamdude:
    image: ghcr.io/kainpl/bamdude:latest
    container_name: bamdude
    network_mode: host          # потрібно для SSDP
    cap_add:
      - NET_BIND_SERVICE        # потрібно для порту 990
    volumes:
      - bamdude_data:/app/data
      - bamdude_logs:/app/logs
    environment:
      - TZ=Europe/Kyiv
    restart: unless-stopped

Маппінг портів не треба — host mode біндить прямо в інтерфейси хоста. UFW / firewalld-правила застосовуй на хості (як у вкладці Linux native).

Обмежена підтримка

Bridge-конфігурація нижче публікує один VP; додавайте його вручну за IP замість покладання на SSDP. Опціональний host networking Docker Desktop не робить аліаси Windows/macOS доступними для bind у контейнері; дивіться розділ про аліаси.

Bridge-mode compose:

services:
  bamdude:
    image: ghcr.io/kainpl/bamdude:latest
    container_name: bamdude
    cap_add:
      - NET_BIND_SERVICE
    ports:
      - "${PORT:-8000}:8000"
      - "3000:3000"
      - "3002:3002"
      - "990:990"
      - "6000:6000"
      - "8883:8883"
      - "322:322"
      - "2024-2026:2024-2026"
      - "50000-50029:50000-50029"   # FTP passive data — покриває 3 VP (по 10 портів на слайс); розшир до 50000-500N9 для N+1 VP, або 50000-50100 для proxy-режиму
    volumes:
      - bamdude_data:/app/data
      - bamdude_logs:/app/logs
    environment:
      - TZ=Europe/Kyiv
      - VIRTUAL_PRINTER_PASV_ADDRESS=192.168.1.100  # LAN IP Docker-хоста
    restart: unless-stopped

VIRTUAL_PRINTER_PASV_ADDRESS у bridge-режимі обовʼязковий — без нього FTP PASV анонсує внутрішній IP контейнера і канал даних ламається у середині хендшейку.

У налаштуваннях контейнера ставимо Host Network. FTP-сервер біндиться напряму на 990 — додаткової конфігурації не треба, окрім увімкнення VP в UI.

Спецконфігурації не треба — FTP-сервер біндиться напряму на 990. BamDude крутиться як root або з CAP_NET_BIND_SERVICE на бінарі Python (див. вкладку Linux native).

UI вибору режиму¶

Діалог Add / Edit показує чотири режими як три великі кнопки + sub-toggle — бо print_queue і auto_queue це по суті два варіанти одного й того самого (диспатч у чергу, з фіксованим таргетом vs без):

┌──────────────────────────────────────────────────────────┐
│  Mode                                                    │
│  ┌─────────────┬───────────────┬──────────────────────┐  │
│  │   Queue     │  File Manager │    ⇄  Proxy          │  │
│  └─────────────┴───────────────┴──────────────────────┘  │
│                                                          │
│  Коли вибрано Queue:                                     │
│    [ ] Auto-select printer  ← тогл                       │
│        on  → mode = auto_queue                           │
│        off → mode = print_queue + поле Target Printer    │
│                                                          │
│  Auto-dispatch                          [ ]              │
└──────────────────────────────────────────────────────────┘

Коли Queue → Auto-select printer = on — VP у режимі auto_queue, дропдаун Target Printer зникає (будь-який принтер відповідної моделі підбере). Коли Auto-select = off — режим print_queue і дропдаун Target Printer, на який завжди йдуть аплоади.

file_manager і proxy — це окремі повноширокі кнопки.

Звʼязка Model ↔ Target Printer¶

У режимі print_queue діалог звʼязує Model і Target Printer, щоб не вийшло несумісної пари:

Вибираєш Target Printer — Model автоматично заповнюється з моделі того принтера.
Вибираєш Model — список Target Printer фільтрується за цією моделлю. Якщо раніше вибраний таргет не підходить новій моделі — діалог чистить його.
В полі Target Printer є явна кнопка очистки (×), якщо хочеш скинути вибір без зміни моделі.

Правила валідації¶

Backend (POST /virtual-printers/, PUT /virtual-printers/{id}) енфорсить:

Правило	Помилка
`mode='print_queue'` + `auto_dispatch=true` + немає `target_printer_id` (і не перемикаєшся в auto-select)	400 — "Auto-dispatch in Queue mode requires a Target Printer. Pick a target, enable Auto-select printer, or turn Auto-dispatch off."
`mode='proxy'` без `target_printer_id`	400 — "Proxy mode requires a Target Printer."
Будь-яке інше значення `mode`	400 — "Invalid mode."

Маршрут PUT перевіряє остаточний стан після застосування body — не можна обійти правило, чистячи поля по одному. Якщо треба прибрати існуючий таргет — шли clear_target_printer: true (кнопка × в діалозі це й робить).

Frontend дзеркалить це жовтим попередженням, що відключає тогл Auto-dispatch, коли комбінація небезпечна — обмеження видно ще до сабміту.

Що робить режим `file_manager`¶

Аплоад зберігається просто в бібліотеку File Manager як звичайний файл — той самий рядок, ті самі теки й теги, що й у файлів, завантажених через UI. Нічого не друкується і нічого не ставиться в чергу; файл просто лежить, доки хтось із ним щось не зробить.

З бібліотеки оператор обирає файл і користується звичайним Print / Add to queue — тим самим шляхом диспатчу, що й будь-який інший друк.

Дві поведінки, які варто знати:

Зберігається лише .3mf. Усе інше, що надішле слайсер, відкидається одразу, а не складається.
Через бібліотеку йдуть усі режими. print_queue і auto_queue теж спершу зберігають файл сюди, а вже потім ставлять у чергу отриманий library-файл — тож бібліотека є повним записом того, що VP отримав, у якому б режимі він не працював.

Окремої черги рецензування більше немає

Раніше аплоади парковались у таблиці pending_uploads з власною review-модалкою. У 0.4.2 це згорнули в бібліотеку, таблицю злила міграція m041, а її саму разом з ендпоінтами прибрали у 0.4.3. Якщо ви йдете за старішим гайдом — review-модалки й ендпоінтів /api/v1/pending-uploads/… більше не існує.

Auto-dispatch (режими черги)¶

VP у будь-якому режимі черги (print_queue чи auto_queue) підкоряється флагу auto_dispatch:

`auto_dispatch`	`print_queue`	`auto_queue`
true	Аплоад зі слайсера → архівується → ставиться в чергу → диспатчиться одразу.	Аплоад зі слайсера → архівується → кидається в авто-чергу → наступний 30-секундний тік призначає елемент придатному вільному принтеру.
false	Аплоад зі слайсера → архівується → стає в чергу як `pending`, чекає на explicit Start-клік у queue UI.	Аплоад зі слайсера → архівується → router-рядок створюється з `manual_start=true`, тож планувальник його ігнорує, поки не звільниш через панель авто-черги.

Тільки trusted upstream

Auto-dispatch прибирає human gate. Використовуйте його, коли upstream-джерело — це ви самі або trusted-автоматизація (slicer plugin, CI job, MakerWorld webhook). Для shared / multi-tenant аплоадів краще режим file_manager + review-модалка.

Per-VP G-code injection¶

Обидва VP режиму черги (print_queue і auto_queue) мають на картці VP тоглер G-code injection. Увімкни його — і кожен джоб, який цей VP ставить у чергу, помічається так, що диспетчер вплітає per-model start / end сніпети в gcode при диспатчі — той самий рушій G-code injection, що й per-item тоглер черги, лише застосований автоматично до slicer-silent аплоадів цього VP.

Вимкнено за замовчуванням, і no-op, доки для цільової моделі принтера реально не існують start / end сніпети.
Перемикання рестартить VP (лісенери переініціалізуються), тож слайсер може коротко побачити, як принтер зникає і з'являється.

Використовуй, коли VP завжди годує одну модель, якій потрібна фіксована преамбула chamber-heat-soak / purge / swap-mode, щоб не пам'ятати про per-item тоглер на кожному send.

Використовувати слоти AMS зі слайсера¶

Типово вимкнено. У режимі черги з конкретним цільовим принтером ця опція зберігає фізичні слоти, обрані слайсером. Це допомагає розрізнити дві котушки однакового матеріалу й кольору.

Таке призначення не дає автоматичному підбору замінити обрану котушку на порожнішу або іншу відповідну. Проте перевірка повноти, матеріалу, сопел і поточного джерела перед запуском залишається. Неповне чи застаріле фізичне призначення потребує перевірки; воно не надсилається сліпо. Повністю невизначений список слотів від слайсера не вважається фізичним вибором.

У режимі Auto-Queue немає закріпленого принтера: джерела визначаються для машини, яку обере розподільник. Опція збереження слотів не переносить номери AMS від одного принтера на всю ферму.

В обох режимах черги явне вимкнення Use AMS у завданні слайсера зберігає обмеження лише зовнішньої подачі. Увімкнене дозволяє автоматично вибрати підтримувану подачу; воно не створює AMS на принтері, де його немає. Плита, використані канали та прив'язки сопел перевіряються зі самого файла. Див. Призначення філаменту.

Системні дефолтні print-опції (slicer-silent диспатчі)¶

Коли слайсер шле друк на VP у режимі черги, він зазвичай несе per-job тогли print-опцій — bed levelling, flow calibration, layer inspection і timelapse. Деякі білди слайсерів і headless / скриптові шляхи аплоаду ці флаги не передають. Раніше queue item з відсутнім флагом одразу падав на built-in column-дефолт моделі принтера.

Тепер queue item резолвить кожен із цих чотирьох флагів за таким пріоритетом:

Пріоритет	Джерело	Коли застосовується
1 (найвищий)	Значення зі слайсера	Слайсер передав явний вибір для флага. Завжди виграє.
2	Per-model системний дефолт	Слайсер флаг не передав і для цієї моделі принтера налаштований системний дефолт.
3 (фолбек)	Built-in column-дефолт	Ні те, ні інше — захардкожений дефолт моделі.

Лише заповнює прогалини — ніколи не перевизначає слайсер

Флаг, який слайсер передає, завжди виграє. Системний дефолт існує лише щоб заповнити тогли, які мовчазний слайсер лишив порожніми; він ніколи не перевизначає явний вибір у слайсері.

Налаштування системного дефолту¶

Системні дефолти живуть поряд із per-user saved-профілями у Settings → Print → Saved Print Profiles. Таблиця профілів тепер пропонує псевдо-користувача "System (slicer fallback)" на додачу до реальних користувачів:

Відкрий діалог Add / Edit профілю.
Обери System (slicer fallback) як користувача.
Вибери модель принтера, до якої застосовуються дефолти.
Вистав чотири тогли і збережи.

Системний дефолт — щонайбільше один на модель принтера: вибір тієї ж моделі ще раз редагує існуючий, а не створює дубль.

use_ams не є системним дефолтом

use_ams — не один із тоглів saved-профілю, тож його навмисно виключено із системного дефолту. Використання AMS лишається slicer-sent-or-column-default — виставляй його у слайсері (або покладайся на built-in дефолт моделі), не тут.

Приклад — завжди timelapse на флоті P1S

Щоб форсити timelapse на кожному slicer-silent диспатчі до твоїх принтерів P1S — навіть із білда слайсера, що не передає флаг — додай профіль System (slicer fallback) для моделі P1S з увімкненим timelapse. Кожен queue item, що лягає на P1S без явного вибору timelapse, тепер його успадковує.

Режим auto_queue¶

auto_queue — це природна спарка ВП з авто-чергою. На отриманні аплоада ВП:

Архівує 3MF (повна per-plate metadata, мініатюри, source-hash chain).
Викликає extract_auto_queue_requirements на заархівованому файлі — витягує:
- target_model (з sliced_for_model у 3MF)
- required_filament_types (з slice_info.config)
- plate_id, якщо слайсер вказав конкретний плейт
Створює AutoQueueItem з manual_start = !auto_dispatch.
Повертає FTPS-успіх слайсеру — той самий UX, що й справжній принтер, який прийняв файл.

Далі підхоплює маршрутизатор: 30-секундний тік, пошук придатного принтера, AMS-мапінг на момент призначення. Повний потік маршрутизації — у доку про авто-чергу.

У режимі auto_queue поля Target Printer не існує — це й сенс. Діалог приховує його і чистить значення, якщо лишилося після переключення режиму.

Джерело імені архіву¶

За замовчуванням 3MF, заархівований через VP, бере display-name з print_name з project-метадаt — це зазвичай людськочитабельне "Calibration Cube v3", набране оператором у Bambu Studio. Деякі workflow'и віддадуть перевагу upload-filename замість того — наприклад, batch-система, що називає кожен upload 2026-04-30_jobid-1234.gcode.3mf і хоче зберегти ці ідентифікатори як є.

Settings → Virtual Printer → Archive name source:

Значення	Ефект
`metadata` (default)	Брати 3MF-метадані `print_name`. Падає на filename, якщо метадані відсутні.
`filename`	Брати stem upload-filename'а. Падає на метадані, якщо filename порожній / generic.

Тоглер install-wide, застосовується до кожного VP крім proxy-mode (proxy-uploads BamDude'ом не архівуються — flow архіву реального принтера бере на себе).

PASV Address (NAT / Docker bridge)¶

FTPS використовує команду PASV — сервер каже клієнту, на який IP передзвонити для data-каналу. Коли BamDude працює в Docker bridge мережі (або за будь-яким NAT), PASV-відповідь інакше анонсувала б внутрішній IP контейнера — слайсери в LAN не зможуть до нього достукатися, і data-канал зафейлиться посеред handshake-у.

Поставте env-змінну VIRTUAL_PRINTER_PASV_ADDRESS на externally-reachable IP (LAN-адресу хоста — більшість слайсерів тут не резолвлять hostnames):

VIRTUAL_PRINTER_PASV_ADDRESS=192.168.1.100

FTPS-сервер стартує, логує FTP PASV address override: 192.168.1.100, і відтепер кожна PASV-відповідь використовує цю адресу. Не має ефекту, коли BamDude крутиться на host-мережі — там не задавайте.

Troubleshooting¶

Слайсер не знаходить VP (auto-discovery)¶

VP увімкнено і запущено? Бейдж на картці VP має бути Running — якщо Error, відкривай картку і читай причину.
Той самий LAN-сегмент? SSDP — link-local: не пройде через VPN tun, Docker bridge, маршрутизовані підмережі. Додавай вручну за IP.
Bind-порти досяжні? З машини зі слайсером:
```
nc -zv BAMDUDE_IP 3000
nc -zv BAMDUDE_IP 3002
```
Фаєрвол: 3000/tcp, 3002/tcp, 2021/udp мають бути відкриті між слайсером і BamDude.
Кілька NIC? Network Interface Override — пін SSDP на потрібний інтерфейс.

VP не запускається: відсутня локальна IP або зайняті порти¶

Windows WinError 10049 / Linux Cannot assign requested address: налаштований Bind IP локально недоступний. Перевірте Get-NetIPAddress -AddressFamily IPv4 у нативній Windows або ip -br addr у Linux. Додайте аліас до правильного адаптера й дочекайтеся його готовності. Резервація на роутері та Network Interface Override не створюють аліас.
Address already in use: потрібні IP/порт зайняті іншим VP або сервісом. Перевірте Get-NetTCPConnection -State Listen у Windows або ss -ltnp у Linux. Для одночасної роботи VP використовуйте різні локальні IP; не зупиняйте сторонню службу, не встановивши її призначення.
Після виправлення адреси/порту вимкніть та знову увімкніть відповідний VP. Це повторює запуск без перезапуску всього BamDude. Перевірте статус роботи та журнал, потім доступ із ПК зі слайсером.

У збірках із виправленням очищення запуску невдалий non-proxy VP звільняє частково запущені слухачі й MQTT-міст та залишається зупиненим. Старі збірки могли писати services started одразу після bind-помилок; цей рядок не доводив успішного запуску. Помилки bind та довіри до сертифіката — різні проблеми. Дивіться значення помилок сокетів Windows.

"Failed to connect" / TLS error -1 / cert untrusted¶

Слайсер не довіряє CA BamDude. По черзі:

CA дописаний у printer.cer?
```
grep -c "BEGIN CERTIFICATE" "/path/to/slicer/resources/cert/printer.cer"
```
Stock = 1. Після append = 2 (або більше при мульти-host).

Той CA? Якщо переніс BamDude на новий хост — CA інший. Звіряй fingerprint:

# Native
openssl x509 -in data/virtual_printer/certs/bbl_ca.crt -noout -fingerprint -sha1

# Docker
docker exec bamdude openssl x509 -in /app/data/virtual_printer/certs/bbl_ca.crt -noout -fingerprint -sha1

Рядок SHA1 Fingerprint=… має бути серед сертифікатів у printer.cer.

Слайсер повністю перезапущений? Cmd+Q на macOS, End Task на Windows. Закрити вікно недостатньо — printer.cer не перечитується.
Linux AppImage / Flatpak: printer.cer всередині бандла read-only. Або розпаковуй AppImage і редагуй вшитий cert, або ставимо CA в системний trust store + перевіряємо tls_cert_store_accepted: yes у ~/.config/BambuStudio/BambuStudio.conf.
Останній варіант — регенерація:
```
rm -rf /path/to/data/virtual_printer/certs/
# disable + re-enable VP в UI для регенерації
```
Потім переімпортуй новий CA у кожен слайсер.

"Wrong printer model"¶

Модель пресета слайсера і SSDP-код VP не збігаються. Постав однакову модель з обох боків — перевірка сумісності читає саме SSDP-код VP.

Authentication failed¶

Access code — рівно 8 символів, ні більше, ні менше.
Слайсер кешує access code per discovered printer; якщо ти змінив його у BamDude — видали і додай принтер у слайсері знову.

Не той IP в SSDP / TLS SAN не співпадає¶

Хост з кількома NIC (Tailscale, Docker bridges, dual LAN) — авто-detect взяв не той інтерфейс:

Settings → Virtual Printer
Network Interface Override → інтерфейс, з якого слайсер реально дотягується до BamDude
VP перезапуститься; SSDP і SAN сертифіката оновляться

FTP error / connection reset¶

Права на <DATA_DIR>/virtual_printer/ — має бути writeable юзером, від якого крутиться BamDude.
Порт 990 вже занятий? sudo ss -tlnp | grep :990 — вимкни конфліктуючий FTP.
CAP_NET_BIND_SERVICE нема — див. Linux native вище.
Bridge-режим Docker — VIRTUAL_PRINTER_PASV_ADDRESS обовʼязковий; без нього PASV анонсує внутрішній IP контейнера, і канал даних рветься.

Слайсер каже "The printer is busy with another print job"¶

Слайсер відмовляється надсилати, бо бачить VP як «у процесі друку». Це стан preparing — VP переходить у нього щойно ти починаєш send, і знімає його коли аплоад завершується.

Виправлено у 0.4.5. До 0.4.5 обірваний чи невдалий аплоад (або файл, що прийшов не як .3mf) міг лишити VP застряглим у preparing аж до рестарту BamDude — і кожен наступний send бачив його зайнятим. Тепер VP завжди повертається в готовність коли аплоад завершується — успіх чи помилка, будь-який тип файлу — і репортує preparing лише поки аплоад справді триває. Якщо ловиш це на 0.4.5+ — має зникнути саме протягом одного статус-циклу.
Воркераунд на старіших білдах: перемкни VP off→on (або пере-збережи його конфіг), щоб скинути стан; рестарт BamDude робить те саме.
Стосується всіх non-proxy режимів (Файловий менеджер, Черга, Авто-черга) і обох слайсерів — Bambu Studio та OrcaSlicer.

Proxy mode: принтер offline у слайсері¶

Target принтер у BamDude онлайн? На сторінці Printers картка має показувати Online.
Принтер у LAN Mode (Developer Mode у Bambu Handy)? Proxy режим вимагає LAN mode — у Cloud Mode проксована MQTT-сесія відхиляється.
Перемкни proxy off + on, щоб форснути reconnect.

Proxy mode: попап "Connect using IP and access code" при Print¶

Порт 6000 досяжний? Bambu Studio через нього шле тунель файлу.
```
nc -zv BAMDUDE_IP 6000
```
Фаєрвол: 6000/tcp між слайсером і BamDude.
Різні VLAN / підмережі — глянь у логах BamDude IP rewrite active. Крок MQTT IP-rewrite перепаковує LAN-IP принтера у MQTT-payload на IP BamDude, щоб слайсер ішов у proxy, а не напряму.

Proxy mode: камера не вантажиться¶

X1 / H2 / P2: RTSP на 322 — відкрити між слайсером і BamDude.
A1 / P1: камера їде через 6000 (спільно з file transfer).

Proxy mode: розривається посеред передачі¶

Великі 3MF на повільному uplink. Або підняти VPN (Tailscale / WireGuard), щоб канал даних ішов одним стабільним тунелем, або заливати 3MF локально, а далі диспатчити Print Queue.

Технічні деталі¶

Безпека по протоколу¶

Bind (3000, 3002): нешифрований TCP — передає тільки ідентифікацію принтера, без чутливих даних. У proxy режимі BamDude відповідає від імені VP і не форвардить bind на принтер.
MQTT control (8883): TLS 1.2, термінується в BamDude. Proxy режим переписує IP принтера всередині MQTT-payloads, щоб слайсер не міг обійти проксі.
File transfer tunnel (6000): end-to-end TLS, прозоре проксі.
RTSP camera (322): end-to-end TLS, прозоре проксі.
A1 / P1S proprietary (2024–2026): end-to-end TLS, прозоре проксі.
FTPS control (990): end-to-end TLS, прозоре проксі.
FTP data (10-портовий слайс на VP від 50000; proxy-режим форвардить діапазон таргет-принтера): у proxy режимі — прозоре проксі; реальне шифрування залежить від домовленості слайсера/принтера. Bambu Studio шле дані каналом у відкритому вигляді навіть коли узгоджує PROT P. VPN — якщо тобі треба конфіденційність каналу даних.
Усі зʼєднання вимагають 8-символьний access code — слайсер автентифікується на кожному TLS-handshake.
CA живе у <DATA_DIR>/virtual_printer/certs/; per-VP device certs у <DATA_DIR>/virtual_printer/certs/{id}/ регенеруються при зміні серійника.

Обмеження¶

Кільком VP потрібен окремий bind IP кожному — interface-аліаси за таблицею вище.
SSDP працює тільки на одній LAN / маршрутизованих підмережах. VPN tun mode і Docker bridge — додавати вручну за IP.
Слайсер повинен довіряти самопідписаному CA BamDude — див. Встановлення сертифікату.
FTP data channel нешифрований з боку слайсера — VPN, якщо хочеш повне шифрування.
Docker Desktop: bridge-приклад вище публікує один VP. Аліаси ОС хоста недоступні для прямого bind у контейнері; нативна Windows підтримує описану вище схему з кількома VP.

Use cases¶

Multi-user farm inbox — file_manager + review-модалка дозволяє кільком людям слайсити у той же VP, не наступаючи одне одному на ноги.
Архівування друку без друку — file_manager + дія bulk-archive у review-модалці перетворює slice → send на постійний запис (мініатюри, metadata, source 3MF) без коміту до друку.
Збирання бібліотеки — той самий file_manager: архівуйте аплоади з review-модалки, щоб прикріплювати їх до проєктів, batch-друкувати або шарити з командою до першого білда.
Hands-off на одну машину — print_queue з фіксованим Target Printer + auto_dispatch=true — це найближче до "Cloud Print, але локально" для одного принтера.
Ручний gate на черзі — print_queue + auto_dispatch=false ставить аплоад у чергу, але чекає на explicit Start-клік перед тим, як диспетчер його забере.
Load-balancing на фермі — auto_queue + auto_dispatch=true — це killer-флоу для багатопринтерної ферми: слайсер не знає, який принтер виконуватиме друк, маршрутизатор обирає на момент диспатчу.
Віддалений друк — режим proxy пробрасує remote-слайсера TLS-сесію прямо в реальний принтер, з сертифікатом BamDude як публічним обличчям.

Поради¶

Один VP на workflow

Ніщо не заважає крутити кілька VP одночасно на різних IP — один на production auto-dispatch, один на review, один на архівування. Вони шарять той самий backend, тож усі дані залишаються уніфікованими.

Slicer auth caching

Bambu Studio / OrcaSlicer кешують access-код per discovered принтер. Поверніть VP access-код — і слайсери знову спитають, без ручної очистки кешу.

Початково базується на документації Bambuddy.