Перейти до змісту

Черги для кожного принтера

Ставте друки в чергу та плануйте їх з незалежними чергами для кожного принтера, перетягуванням, розміром партії та розумною автоматизацією.

Черга на другому екрані

Натисніть Відкрити монітор, щоб перейти до монітора стану. Подання Черга показує поточний друк, паузу чи причину очікування, наступне завдання й ETA черги в однакових плитках. Монітор лише показує інформацію; керуйте завданнями на робочій сторінці.

Огляд

Черга друку дозволяє:

  • Ставити друки в чергу з архівів або файлового менеджера
  • Черги для кожного принтера -- кожен принтер має свою незалежну чергу
  • Розмір партії -- друк кількох копій одразу (кожна копія живе в черзі, без особливої "головної" копії)
  • Перетягування для зміни порядку
  • Запланований час старту
  • Вигляд таймлайну -- графік виробництва з розрахунковим часом завершення
  • Розмір карток -- S / M / L / XL, як на сторінці принтерів; визначає кількість карток у рядку й запам'ятовується в браузері
  • Сортування за ETA -- завершення поточного друку або всієї черги; друге використовує серверний прогноз черг, див. Моніторинг
  • Сортування за тегом -- картки згруповані за тегами принтера; принтер із кількома тегами входить до кожної групи, «Без тегу» стоїть останньою, крапка групи має колір тегу
  • Призначення за моделлю -- ставиш у чергу «будь-який принтер відповідної моделі», а машину добирає авточерга
  • Автоматизація розумних розеток -- автоматичне вмикання/вимикання

Слайсь-і-в-чергу одним кліком, і спершу прогрій стіл

Дві супутні функції стоять поруч із чергою: Налаштування слайсингу зберігають налаштування слайсу, щоб підставити всі чотири пресети в діалог Slice одним вибором, а Прогрів і heat-soak тримає стіл (і, де підтримується, камеру) на температурі перед стартом друку інженерним філаментом.

Архівовані принтери зникають з view черги

Архівування принтера ховає його картку черги тут і скасовує його pending-елементи — архівований принтер ніколи не є ціллю диспатчу.

Принтеру треба, де тримати завдання

Принтер Bambu друкує зі свого сховища, тож файл спершу має туди потрапити. На більшості моделей це означає, що SD-карта обовʼязкова — без неї кожен диспатч падає на аплоуді. Власники A1 mini часто крутять без SD; ця модель чергу не тягне.

X2D, P2S і сімейство H2 мають ще й вбудоване сховище, і BamDude шле туди, коли картки немає — ці машини тягнуть чергу з порожнім слотом.

Стани черги

Стан тут несуть дві різні речі, і сплутати їх легко. Черга належить принтеру — вона в нього рівно одна, і її id є id принтера. Елементи — це завдання, що в ній стоять. Набори станів у них різні й не перетинаються.

Черга

Стан Значення
idle Тут нічого не диспатчено; планувальник може взяти наступний елемент цієї черги.
printing На принтері друк іде або ось-ось почнеться. Це авторитетна позначка зайнятості — планувальник набирає свій «busy»-набір саме з цих рядків, і саме тому черга лишається зайнятою на весь час свап-макроса після друку, хай що каже живий MQTT.
paused Виставляється автоматично після скасування під час диспатчу. Нічого не зламалось — оператор перервав один елемент, тож решта черги чекає, а не мчить далі.
error Виставляється автоматично після збою диспатчу.

is_paused — це окрема колонка, ортогональна до status: власний тумблер паузи від оператора. Черга може бути одночасно printing і is_paused (паузу взяли посеред друку): поточний друк спокійно доходить до кінця, просто наступний елемент не піде, доки не знімеш паузу. Планувальник пропускає чергу, якщо стоїть будь-який із двох сигналів, — тому одна кнопка Resume знімає обидва разом.

Запаркована черга все одно приймає роботу

Ні is_paused, ні статус paused / error не заважають класти в чергу нове — з будь-якого діалогу. Їх читає лише планувальник, і завдання, покладене на запаркований принтер, просто чекає там видимо.

Елементи

Кожен елемент черги має рівно один із шести станів (видно у chip-ах на картці):

Стан Значення
pending У черзі. Стартує, коли принтер вільний, запланований час минув і ніщо інше не тримає.
printing Диспатчено. Виставляється в мить, коли забрано claim черги, — до початку FTP-аплоуду.
completed Друк завершився. Рядок зазвичай зникає одразу — його історія лишається в архіві, — але там, де озброїться гейт очищення столу, він чекає на твою відповідь: Очистити стіл прибирає його, Повторити друк переозброює той самий рядок на ще одну копію.
failed Диспатч або друк зафейлився; докладний error_message на ховері.
skipped Гейт require_previous_success відмовив, бо попередній друк на цьому принтері впав. В error_message — «Previous print failed». Unskip знімає гейт саме з нього.
cancelled Скасовано до завершення — тобою або автоматично, коли зникло джерело: викидання архіву в кошик скасовує його ще-pending елементи з причиною «Source archive deleted», а викидання файлу бібліотеки — з «Source file deleted». Рядок лишається на видноті зі своєю причиною, а не щезає: завдання, яке зникло мовчки, не відрізнити від того, якого ніколи не ставили.

Стану paused в елемента немає. Друк на паузі на принтері — оператор, runout, проблема AMS — це стан принтера, який читається живцем із машини; елемент черги весь цей час лишається printing.

Очікування — теж не окремий стан. Елемент, який планувальник подивився і вирішив поки не стартувати, лишається pending і несе окреме текстове поле waiting_reason, видиме в рядку: «Printer offline», «Drying in progress», «Plate not cleared», рядок поетапного запуску з тим, кого він чекає, або «Swap macro failed: …». Причина переписується на кожному проході і обнуляється щойно принтер готовий, — тож вона завжди показує останній тік, а не стан, у якому рядок застряг.

Хедер картки черги показує лічильники двох сортів. Pending і Skipped кешуються на самому рядку черги й перераховуються при кожній зміні; Total / Completed / Failed / Cancelled рахуються з print_archives через archive.queue_id у момент читання — тож вони не пливуть, коли живі рядки прибираються.

Додавання до черги

Постановка файлу бібліотеки в чергу питає, для якого це замовлення

Діалог несе поле Замовлення зі списком відкритих замовлень, яким цієї плити ще бракує, із числом друків, яких кожному з них не вистачає, і виробом, для якого воно. Перше, якому плити бракує, обране одразу, а Без замовлення доступне завжди. Обране одразу рахує план того замовлення. Див. Підшивання друку під замовлення.

З архіву

  1. Перейдіть на сторінку Архіви
  2. Натисніть кнопку Запланувати на картці архіву
  3. Оберіть цільовий принтер(и)
  4. За бажанням налаштуйте маппінг філаментів
  5. Друк додано до черги

З файлового менеджера

  1. Оберіть нарізані файли у Файловому менеджері
  2. Натисніть Додати до черги на панелі інструментів
  3. Оберіть цільовий принтер

Поставити наступним на вибраному принтері

Коли з'являється термінове завдання, оберіть його принтер у діалозі Запланувати друк, лишіть режим ASAP і позначте Поставити наступним. Нове завдання стане перед іншими очікуючими завданнями цього принтера. Воно не перериває друк, який уже запущено або захоплено для відправлення.

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

Поставити наступним навмисно недоступне для Лише черга, запланованого друку й Авточерги. Ці режими мають власну семантику запуску; опція не резервує принтер і не шукає той, що звільниться першим.

Drag-and-drop на картку черги

На сторінці Черги кожна картка черги принтера є drop-target — і кожна картка на сторінці Принтери теж. Кидайте скільки завгодно файлів: кожен завантажується в корінь бібліотеки, а далі файли, на які відповідь була б однакова, групуються — один діалог на групу, з бейджем група 1 з 3 · 12 одиниць біля заголовка, який каже, скільки плит накриває ця одна відповідь. Модалка припнута до цього принтера — без тогла specific/auto, і сам принтер показано відміченим, зняти вибір не можна, бо drop-target і є вибір. Статус принтера на картці (idle / printing / paused / error) не перевіряється: додавати в чергу можна завжди, незалежно від того, що принтер зараз робить.

Кожен файл дістає свіжу модалку. Вибір плити, мапінг філаменту й per-printer опції належать одному файлу; переносити їх на наступний — не зручність, а помилка: плити 3 в наступному файлі може не існувати.

За кожен кинутий файл є відповідь, поіменно:

відхилено чому
взагалі не .3mf нічого іншого принтеру Bambu по мережі не надішлеш
сирий .gcode прошивка Bambu у LAN-режимі читає лише контейнер .gcode.3mf; сирий .gcode падає вже на принтері, за півхвилини після старту
.3mf без нарізаного G-code усередині вирішується за вмістом файла, а не за іменем — .3mf може бути і готовим друком, і голою моделлю
немає записаної моделі принтера зіставляти нема з чим: ні з ціллю авточерги, ні з цим принтером
нарізано під іншу модель плита не та або G-code не піде

Якщо кинутий файл уже є в бібліотеці, вам це скажуть і використають наявну копію — див. дедуплікацію.

Несумісність sliced_for_model з моделлю принтера на картці перериває аплоуд до відкриття модалки — тимчасовий рядок бібліотеки відкочується, тост виводить конфлікт, щоб можна було перерізати під правильний принтер.

Захищено правом queue:create — у в'юверів без нього оверлей не з'являється і drop ігнорується.

Один діалог на групу

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

Спільна відповідь для групи Перевіряється для кожного файлу й плити
Принтер або авточерга, цільова модель і розташування Обрані плити та їхні справжні номери
Розклад, кількість, опції друку й макроси Використані канали й повне призначення джерел
Загальні правила подачі й точного кольору Налаштування окремих каналів і ручні фізичні призначення

Колір сам по собі не ділить групу, але правила кольору перевіряються окремо для кожного файлу. Галочка групування не дозволяє підміняти закріплений колір чи переносити вибір каналу між файлами. Якщо ви змінили канал поточного файлу, наступний файл відкриється для перевірки; форма пояснює це.

Відсутній матеріал на обраному принтері може повернути діалог для відповідного файлу. Авточерга може прийняти коректний файл для очікування, але ані групування, ані вибір кількох принтерів не обходять перевірку джерела та повного призначення перед запуском. Див. Призначення філаменту.

Відмовитись від групи

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

Галочка належить групі, а не прогону: наступна група відкриється знову з увімкненою. Відповісти на першу групу групою, другу передивитись пофайлово, а третю знову пустити групою — звичайний прогін.

Мультиплейтний файл дає кожну свою плиту

Кожна плита — самостійна одиниця, тож трьохплитний файл відкривається з усіма трьома натиснутими плитами й ставить три позиції там, де раніше ставив одну. Галочки на екрані, зайві можна зняти, але діалог більше не починає з самої лише першої плити.

Маппінг філаментів AMS

Для обраної плити задайте джерела кожного використаного каналу: AMS або підтримувану зовнішню подачу. Автоматичний підбір враховує матеріал, колір і сопло. Дозволити збіг за базовим матеріалом увімкнено типово: розв'язане сімейство дає свій filament_type (наприклад PETG) замість назви профілю чи вендора; коли перемикач вимкнений, відомий різновид профілю лишається обмеженням. Ручний вибір фізичного слота зберігається як обмеження, яке перевіряється знову перед стартом. Див. зіставлення матеріалу.

На підтримуваних двосоплових принтерах позначки [L] / [R] показують прив'язку до сопла. Підтримка не обмежена H2D чи X2D: використовуються можливості моделі й поточна конфігурація. Змішана подача AMS + зовнішня або дві окремі зовнішні подачі допустимі лише за правильних прив'язок обраної плити.

Завдання зберігає правила подачі й кольору під час зміни розкладу, повтору або клонування. Ручне призначення для іншого принтера чи плити потрібно підтвердити заново. Повні правила й причини очікування.

Спорожнювати першою найпорожнішу котушку (prefer_lowest_filament) — це фермерське налаштування, увімкнене типово, у Налаштування → Філамент → Перевірки філаменту. Після сумісності й переваги точного кольору воно бере джерело з меншим залишком серед інших однаково придатних, щоб першими витрачалися майже порожні котушки. Відстежувані AMS-котушки використовують грами BamDude/Spoolman; джерела лише з прошивкою використовують її відсоток в окремому нижчому рівні. Той самий перемикач керує маппінгом авто-черги при диспетчеризації та збереженим маппінгом віртуального принтера. Див. повне ранжування.

Це залежить від AMS Filament Backup. Коли backup вимкнено, принтер не авто-перемикається між spool-ами того ж матеріалу mid-print, тож BamDude пропускає prefer-lowest і матчить звичайно — інакше джоб міг би застрягти, коли обрана майже-порожня бабіна закінчиться без чого падати назад. Коли backup увімкнено — поводиться як описано вище; невідомий стан backup (наприклад, старіший протокол A1) зберігає prefer-lowest поведінку. Гейт діє на обидва dispatch-шляхи — queue scheduler і auto-queue router.

Кожна плита має власне призначення

Кілька обраних плит отримують окремі панелі й окремі призначення. Використані канали однієї плити не об'єднуються з каналами іншої. Для кількох принтерів вимоги перевіряються проти конкретного цільового принтера. Залишок філаменту — це вхід для ранжування джерела, а не резервування чи перевірка достатності грамів: перед стартом BamDude повторно перевіряє ідентичність і сумісність призначеного джерела, але не обіцяє, що повідомленого залишку достатньо для розрахованих слайсером грамів.

Дані сопла перевіряються перед запуском

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

Вибір плити (мульти-плейт 3MF)

Мульти-плейт 3MF несе всі плити в одному файлі. Модалка Add-to-Queue рендерить плейт-grid:

  • Клік на одну плиту — диспатч тільки її (рядок черги записує це як plate_id).
  • Multi-select плит → один рядок на плиту, у порядку.
  • Попередній перегляд показує мініатюру й філаменти кожної плити; сервер перевіряє обрану плиту за джерелом перед постановкою в чергу.

plate_index зберігається через restart-recovery + reprint. Деталі chain-of-custody мульти-плейтних диспатчів — archiving.

Вибір Весь файл допустимий лише для однієї однозначної друкованої плити. Її номер зберігається, навіть якщо це не 1; багатоплитний файл потребує явного вибору. Перевірка джерела.

Тип build-plate на елементах черги + у діалозі друку

На фермі з купою плит легко загубити, яку саме фізичну плиту потребує зачергований джоб. Кожен pending-елемент черги тепер несе іконку build-plate (наведи — і побачиш назву плити) — та сама bed-іконка, що й на картці архіву — тож ти бачиш цільову плиту з першого погляду, ще до диспатчу. Діалог друку теж показує тип вибраної плити прямо біля plate picker.

Мульти-плейт 3MF резолвяться per-plate: значення перечитує файл під ту плиту, яку ти реально вибрав, а не припускає, що всі плити на bed першої плити — тож файл, що мішає (скажімо) Textured PEI та Engineering plate, маркує кожну коректно.

Опції друку

Розкривай Print options при додаванні в чергу:

Опція Default Що робить
Bed levelling on Auto-bed-level перед друком. Off — швидші рестарти на стабільному столі. Трипозиційний (off / auto / on) на прошивках, що підтримують — див. нотатку нижче.
Flow calibration on Cal екструзійного потоку на старті. Якість vs throughput. Трипозиційний на підтримуваних моделях.
Nozzle-offset calibration on Лише двосоплові машини (H2D / H2D Pro / H2C / X2D); на односоплових MQTT-шар примусово ставить «пропустити», хай що збережено. Трипозиційний на підтримуваних моделях.
Mesh-mode fast check on Лишиш увімкненим — M970 (vibration probe) плити виконається як нарізано. Вимкнеш — 3MF gcode-патчер закоментує ці рядки дорогою до принтера. На диску файл лишається unpatched; патчаться тільки байти, які летять у принтер.
Layer inspection off Per-layer inspection AI (X1 + H2).
Timelapse off Записати вбудований таймлапс на принтері.
Писати на як машина сама вирішить Який носій зберігає запис — той самий вибір, що й у Bambu Studio. Показується лише там, де принтер має обидва: вбудоване сховище і справну SD-картку; з одним носієм вибирати нема з чого, і BamDude не чіпає власний дефолт принтера. Перепитується на старті друку — картку вийняли після постановки в чергу, запис піде у внутрішнє, а не впаде.
G-code injection off Вклеює задані оператором сніпети у gcode плити на диспатчі — див. нижче.
Preheat / heat-soak inherit inherit іде за загальноферменним тумблером прогріву; on / off вирішують за це завдання окремо, з опційною явною ціллю по камері.

Use AMS — не один із цих тумблерів

Вибирайте подачу в панелі призначення або в полі Джерело філаменту форми Auto. Окремого перемикача в Print options немає. Значення use_ams з API або масового редагування узгоджується зі збереженими правилами; команда запуску відповідає перевіреному призначенню джерел. Сам прапорець не скасовує фізичного вибору слота й не додає відсутнього AMS.

Авто-калібрування (off / auto / on)

На моделях, чия прошивка це підтримує — X2D і H2-сімейство (H2D, H2D Pro, H2C, H2S), плюс P2S та A2L для вирівнювання столу + калібрування потоку — Bed levelling, Flow calibration і (на дво-соплових) Nozzle-offset calibration стають трипозиційними: Off, Auto (принтер сам вирішує, чи потрібен крок для цього завдання) або On (завжди виконувати). Моделі без підтримки лишаються з простим Off / On. Вибір запам'ятовується per printer model, а Off/On поводяться точно як раніше — нова позиція Auto доходить лише до принтера, який її рекламує.

Дефолти запам'ятовуються на пару (оператор, модель принтера): тумблери, які ти виставив у діалозі друку, зберігаються профілем цієї пари, і наступного разу для тієї ж моделі діалог підставить їх сам. Адмін бачить усі збережені профілі у Налаштування → Друк → Збережені профілі друку, може редагувати чи видалити будь-який, скопіювати профіль одного оператора іншому (зручно при онбордингу) і задати помодельний рядок System, який діє на всіх, хто власного профілю не має. Те, що ти змінив у діалозі для одного завдання, перебиває все це — але тільки для нього.

Auto-print G-code injection

Іноді треба змінити gcode на диспатчі — chamber heat-soak, кастом purge, swap-mode setup — без re-slice. Тогл G-code injection на елементі черги; самі сніпети, які тримаються на модель принтера, — у Налаштування → Друк → G-code Injection. Сніпети приймають підстановки {placeholder}, які резолвляться проти власного gcode-хедера 3MF, з Prusa→Bambu аліасами — тож сніпет, скопійований із бібліотеки PrusaSlicer ({max_layer_z}), теж розкриється.

Повна довідка: G-code injection. Читається + застосовується на dispatch — різні завдання можуть нести різні injections.

Z-safety

Інʼєкція абсолютних Z-moves до auto-Z-home, який Bambu firmware робить на старті друку, може врізати голову у деталь. Використовуй плейсхолдери (вони експандяться під first-layer plan слайсера), а не хардкоднуті числа.

Аудит created_by_id

Додавання до черги фіксує, хто додав елемент. Telegram-бот, діалог планування з бібліотеки, кнопка "Друкувати" на картці принтера та друки з файлового менеджера -- усі вони пробрасують користувача, який ініціював дію. Видно по рядку на архіві, який згенерує елемент черги. Шляхи через VP auto-queue та webhook-тригер легітимно лишають його NULL (немає автентифікованого користувача, якого можна було б приписати).

Нагрузити чергу з бібліотеки

На картці принтера, на картці попринтерної черги й на панелі авточерги є кнопка Завантажити з бібліотеки. Вона відкриває спрощений файловий браузер: дерево тек ліворуч, невеликі картки праворуч — прев'ю, ім'я, час друку, філамент і розмір.

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

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

Право — queue:create. На картці принтера кнопка не ховається під час друку: нагружати чергу саме тоді й доводиться.

Копіювання черги на інші принтери

Ферма запускає одне й те саме на кількох машинах. На картці черги є кнопка Копіювати — вона з'являється лише коли є що копіювати: іде друк або щось чекає.

Діалог ставить що ліворуч і куди праворуч:

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

На обох боках є «вибрати все» і «зняти все». Список принтерів — у тому ж порядку й групуванні, що й ваш екран черг, тож ви вибираєте з тієї ж розкладки, якою навігуєте.

Чому лише та сама модель

Елементи нарізані під цю машину. Інша модель — інший об'єм друку й інший діалект G-code, а переслайсити BamDude не вміє.

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

Готові елементи черги копіюються зі збереженого файлу, а не з оригіналу. Копія повторно використовує перевірений незмінний обʼєкт з data/queue-sources/, тому працює і після видалення архіву, запису бібліотеки, теки на ноутбуці чи SMB-шари. Для цілі заново вибираються принтер, AMS-мапінг, розклад і параметри друку. Legacy-записи зберігають поведінку через початковий файл; відсутнє або пошкоджене збережене джерело лишається видимим, але його не можна скопіювати.

Далі відкривається звичайна модалка планування — по одній на групу елементів, на які відповідь була б однакова, з усіма обраними принтерами, відміченими й незнімними. Філамент мапиться per printer усередині цієї однієї модалки, тому чотири принтери ніколи не множать кількість діалогів на чотири.

Скопійований елемент зберігає те, що черга вже вирішила. Плита їде разом із ним, тож копія однієї плити п'ятиплитного файлу — це один елемент, а не п'ять, а дві копії тієї самої плити лишаються двома. Замовлення, під яке елемент був підшитий, теж їде з ним — включно з відповіддю «без замовлення», — тож діалог Schedule не перепитує; діалог копіювання показує замовлення поряд із плитою кожного елемента, поки його ще можна зняти з вибору. Якщо в джерелі ви зібрали елементи в блок, на цілі вони теж будуть блоком.

Друк, запущений поза чергою, теж рахується

Робота, надіслана з екрана принтера або просто зі слайсера, не лишає запису в черзі — картка показує її, бо читає принтер напряму, і копіювання читає звідти ж.

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

Перетягування

  1. Наведіть курсор на завдання в черзі
  2. Захопіть ручку перетягування
  3. Перетягніть на нову позицію
  4. Друки виконуються зверху вниз

Планування

Immediate (якнайшвидше)

Default. Завдання стартує, як тільки принтер вільний і диспатчер до нього дійшов. Черга принтера обробляється строго за position.

Scheduled (за розкладом)

Вибираєш майбутню дату + час. Завдання сидить у pending, поки не настане час, потім іде в диспатч. Якщо принтер вимкнений, а в його розетки стоїть auto-on, планувальник вмикає її саме в цю мить і чекає, поки принтер підключиться, — жодного зсуву, який спрацьовує наперед, немає. Треба підняти машину раніше — для цього є власний розклад розетки (проста пара «увімкнути / вимкнути о годині»).

scheduled_time — це гейт, а не ключ сортування

Черга проходиться строго за position: тільки перетягування, кнопки вгору / вниз / bump і шляхи копіювання вирішують, хто наступний. Майбутній scheduled_time змушує планувальник пропустити цей рядок і взятися за той, що нижче; він ніколи не переставляє чергу навколо нього.

Queue only (staged)

Виставляє manual_start = true на рядку — диспатчер ігнорує його, поки не клікнеш Start. Зручно для staging цілої партії наперед і потім release одним рухом (або для аплоудів VP, які треба тримати, поки не переглянеш).

Shortest job first — це налаштування авточерги

Settings → Друк → Маршрутизація авто-черги → Спершу коротші друки (типово вимкнено) змінює порядок, у якому дистриб'ютор авточерги розбирає ще не призначені завдання. Попринтерної черги це не торкається взагалі — та завжди йде за position.

З увімкненим прапорцем pending-елементи авточерги читаються згруповано за цільовою моделлю, далі — коротший прогнозований час друку, далі — позиція. А starvation guard тут — липкий прапорець, а не годинник: після того як завдання розмістили, кожен довший (або з невідомою тривалістю) сусід перед ним у тій самій модельній групі позначається як «перестрибнутий», і на наступному проході перестрибнутий сортується вже попереду решти. Ніякого ageing-скору й ніякого «підняти через N годин» немає: завдання достатньо пропустити один раз, щоб його перестало бути можливо пропускати.

Повний ланцюжок пріоритетів — Auto-Queue Routing.

Керування чергою

Підтвердження очищення столу

Після завершення друку наступний друк не починається автоматично. Картка принтера пропонує дві відповіді: Очистити стіл і почати наступний прибирає завершений рядок і пускає чергу далі, Повторити друк переозброює той самий рядок на ще одну копію (той самий рядок — тож усі опції друку їдуть із ним).

Це попринтерне налаштування, а не загальноферменне: Підтвердження очищення столу стоїть на формі редагування кожного принтера, тож автоматизована комірка може працювати без нього, поки сусідній верстат усе ще питає. На свап-принтерах воно примусово вимкнене: свапер і є очищенням столу.

Брак разом із відповіддю. Коли завершений друк чекає на Очистити стіл, його деталі з'являються поряд із двома кнопками, по лічильнику на кожну; впишіть, що вийшло браком, і натисніть будь-яку відповідь — кількість запишеться в той друк, під тим самим правом. Не торкнуті лічильники нічого не надсилають.

Масове редагування

Виділяй кілька елементів черги через тулбар-checkboxes — далі bulk-edit. Чіпаються лише рядки pending — усе, що вже друкується або завершилось, рахується пропущеним і повертається у відповіді; без queue:update_all так само пропускається все, чого ти сам не ставив у чергу.

Кожне поле необов'язкове: не передав — і кожен рядок лишає своє.

Поле Нотатка
Цільова черга Переносить рядки в чергу іншого принтера. Черга має існувати; повторної перевірки філаменту тут немає — планувальник змапить кожен рядок під той принтер, на якому він урешті опиниться.
Запланований час Ставить один фіксований час на всю вибірку. Форми «зсунути все на N годин уперед» не існує.
Manual start · Auto power-off · Require previous success Три прапорці планування.
Use AMS · Bed levelling · Flow · Nozzle offset · Layer inspect · Timelapse · Писати на · Mesh-mode fast check · G-code injection · Preheat Усі опції друку, плюс вибір свап-макросів і позначених макросів.

Масове скасування — окрема дія, а не поле цього редагування. А в батчів є власні ендпоїнти, які скасовують / пропускають / переупорядковують цілий batch_id за раз.

Групування, згортання і переупорядкування батчів

Приборкай довгу чергу, згрупувавши споріднені pending-джоби на картці черги принтера:

  • Group as batch — вибери 2 або більше pending-айтемів на одній картці, потім Group as batch. Вони ділять batch_id і рендеряться одним блоком. Ungroup розпускає його (completed / cancelled історія зберігає групування). Групування потребує queue:update_all.
  • Collapse — згорни батч до одного summary-рядка; стан collapsed / expanded запам'ятовується per batch у local storage браузера.
  • Drag to reorder — схопи grip handle рядка і перетягни. Доступно лише коли картка повністю розгорнута і на ній немає згорнутих батчів, тож drag ніколи не пересуне прихований рядок чи не розколе батч; кнопки up / down / bump лишаються завжди-доступним fallback.

Вибір скоуплений до однієї картки — батч per-queue, тож вибір не може охоплювати кілька принтерів.

Multi-printer queue + staggered start

Коли подаєш одне завдання на N принтерів одразу (multi-select у Add-to-Queue), кожен отримує свій рядок черги. По дефолту — диспатч одночасно: N паралельних FTP-аплоудів, N майже-одночасних start-команд.

Рознесення цих стартів у часі — це налаштування ферми, а не опція партії: у діалогах Print чи Add-to-Queue вмикати нічого. Увімкни один раз у Налаштування → Друк → Поетапний запуск — і далі кожен старт друку (з черги, Print Now чи запущений з екрана самого принтера) займає один зі скінченної кількості слотів, тож одночасно гріється лише стільки столів, скільки дозволено. Ліміт може бути на всю ферму або розбитий по електричних фазах (теги принтерів) і приміщеннях (розташування), зі своїм числом на кожну групу.

Cross-link: повний deep-dive — Staggered start.

Per-printer AMS-маппінги конфігуряться per-row — multi-printer modal дає reuse одного маппінга, або різний слот per-printer, коли AMS відрізняється у фермі.

Призначення за моделлю ("Any X1C")

Замість пін на конкретний принтер, став у чергу під Any [model]. Таке завдання не потрапляє в попринтерну чергу: попринтерний елемент завжди прив'язаний до однієї машини і поняття «цільова модель» не має взагалі. Воно йде на другий ярус — в авточергу, накопичувач роботи, якій принтера ще не дали:

  • Filament-aware: маршрутизатор пропонує лише принтер, у якого в AMS заряджений потрібний тип філаменту (а з Force colour match — і колір)
  • Location-aware: опційний фільтр локації («будь-який принтер у Workshop A») — це посилання на довідник розташувань, а не текстовий рядок
  • Manual filament override: якщо жоден принтер автоматом не підходить, ставимо ручний маппінг, який маршрутизатор використає незалежно

Поки нічого не підходить, елемент лишається pending в авточерзі і несе власний waiting_reason із тим, чого йому бракує, — статусу waiting_for_filament не існує. Він виходить із цього стану, коли з'являється придатний принтер (тоді маршрутизатор створює справжній елемент у черзі того принтера) або коли ти сам призначаєш його конкретній машині. Маршрутизація ставить лише питання маршрутизації: чи може принтер стартувати просто зараз — гейт плити, сушка, стаггер — питається знову вже на диспатчі, тож елемент, спрямований на зайнятий принтер, просто чекає в його черзі, де його видно.

Повний ланцюжок пріоритетів — Auto-Queue Routing.

Timeline view

Клік List / Timeline угорі сторінки черги — переходимо у Gantt-розклад:

  • Один рядок на принтер, час на X-осі
  • Кожен блок — елемент черги розміром у прогнозований час + ETA chaining (блок N стартує коли блок N-1 закінчився)
  • Day navigation (prev / today / next), фільтри ті самі що у list view
  • Hover на блок — повна деталізація завдання

ETA chaining — це планувальний інструмент, не враховує clear-plate gaps, ручні паузи, filament-loads, тож реальний wall-clock дрейфує довшим. Корисно для відповіді "який принтер цього тижня bottleneck".

Smart plug-автоматизація

Коли принтер привʼязаний до smart-plug, черга може кермувати живленням:

  • Auto power-on (auto_on, типово увімкнено) — коли планувальник доходить до елемента на вимкненому принтері, він вмикає розетку саме тоді і чекає, поки принтер підключиться, і лише тоді диспатчить. Зсуву, який спрацьовує наперед запланованого часу, немає; треба підняти машину раніше — для цього є власний розклад розетки (проста пара «увімкнути / вимкнути о годині»).
  • Auto power-off (auto_off, типово увімкнено) — спрацьовує після завершення або падіння друку і чекає затримку. Два режими затримки: час (типово 5 хв) або температура — тримати, поки принтер не охолоне нижче порогу (типово 70 °C). Окремий тумблер робить те саме після циклу сушки AMS, зі своєю довшою затримкою (типово 10 хв), бо камера після сушки гаряча.
  • На одне завдання — auto_off_after у діалозі додавання в чергу просить вимкнути живлення саме після цього друку.

Повний setup + per-printer linking → Smart plugs.

Історія черги

Коли завдання завершується, його рядок черги зникає — історія лишається в архіві. Старі елементи черги шукати:

  • Сторінка Архіви з фільтром по принтеру — кожен архів несе queue_id + опційний batch_id
  • Failed-диспатчі показують докладний error_message на ховері
  • Bulk-print plans з проєкту лишаються прив'язаними через queue_id linkage

API access

Програмний контроль черги через REST:

Endpoint Призначення
GET /api/v1/queue/ Список елементів черги (фільтр по printer, status)
GET /api/v1/queue/{id}/copy-source Прочитати профіль збереженого джерела для Copy Queue
POST /api/v1/queue/ Додати з архіву, library file або збереженого джерела завдання
PATCH /api/v1/queue/{id} Редагувати position, schedule, AMS, options
DELETE /api/v1/queue/{id} Прибрати рядок повністю
POST /api/v1/queue/{id}/cancel · /stop Скасувати pending-елемент · зупинити той, що друкується
POST /api/v1/queue/{id}/start Відпустити staged-елемент (manual_start) — з перевіркою власності
POST /api/v1/queue/{id}/retry Повернути failed або cancelled у pending, у кінець черги
POST /api/v1/queue/{id}/skip · /unskip Пропустити рядок або зняти з нього гейт попереднього збою
PATCH /api/v1/queue/{id}/manual-start Перемкнути «тільки в чергу» на рядку
POST /api/v1/queue/{id}/clone Ще одна копія наявного рядка
PATCH /api/v1/queue/bulk Масове редагування — лише рядки pending
POST /api/v1/queue/reorder · /{id}/reorder · /{id}/bump · /{id}/bump-bottom Порядок: усією чергою або по одному рядку
POST /api/v1/queue/batch · /batch/{batch_id}/… Згрупувати рядки в батч, далі ungroup / cancel / skip / reorder / bump / clone / edit його як ціле
GET /api/v1/queue/stagger-state Що саме зараз тримає гейт поетапного запуску

Стан черги живе на власному роутері: GET / PATCH /api/v1/queues/{id} читає і виставляє чергу. status приймає лише idle або paused — printing та error виставляє система, ніколи не клієнт, — і чергу не можна перевести в paused, поки вона printing (спершу зупини друк). is_paused, будучи ортогональним, дозволений у будь-якому стані, зокрема посеред друку.

Повна schema + auth: API reference.

Вибір кількох принтерів

Надсилайте один і той самий друк на кілька принтерів одночасно:

  1. Відкрийте модальне вікно Додати до черги
  2. Оберіть кілька принтерів за допомогою прапорців
  3. За потреби налаштуйте маппінг AMS для кожного принтера
  4. Надішліть на всі

Розмір партії > 1 -- єдине джерело правди

Коли ви задаєте кількість N, усі N копій одразу додаються до черги. Вони ділять спільний batch_id (UUID, проштампований на кожній копії), щоб ви могли відповісти "скільки з цієї партії завершилось?" навіть після того, як живі рядки черги приберуться.

Коли вибрано кілька принтерів, N — це на кожен принтер, так типово. Три принтери по 4 дають дванадцять друків — діалог так і каже рядком під полем («4 × 3 принтери = усього 12»). Перемкніть перемикач біля поля на Загальна — і число розкладеться між вибраними принтерами по одній копії по колу, у порядку, в якому їх перелічує список, тож 13 на три принтери стане 5 / 4 / 4, а рядок назве, кому скільки; принтер, якому не дісталось нічого, просто не отримує запиту. Вибір запам'ятовується у вашому браузері. Кількість в авточерзі завжди була загальною, перемикача там немає.

  • Ви можете перевпорядкувати, відредагувати AMS або скасувати кожну копію окремо до її старту.
  • Найперша копія більше не отримує "прямий диспатч" -- кожна копія йде через той самий шлях черги. Це усуває історичну невідповідність "перший архів приземляється попереду N-1 копій, які ще в черзі".
  • Статус відповіді ендпоінта -- "queued" для всієї відправки з N копій; dispatch_job_id та dispatch_position у цьому шляху можуть бути null.

quantity == 1 з одного архіву — це прямий диспатч: він іде одразу, не чекаючи своєї черги. Рядок черги він усе одно займає: з 0.5.4 кожен друк тримає рядок, поки триває, — прямий забирає його на диспатчі, а запущений з екрана самого принтера отримує створений на старті друку. До того «друкувати зараз» не займав нічого, поки принтер справді не починав, тож черга весь час аплоуду бачила вільний принтер і могла диспатчнути просто поверх завдання. Рядок запам'ятовує, звідки він (origin), — саме так сповіщення про завершену чергу не спрацьовують на друки, яких ніхто не планував.

Поведінка диспатчу

Background dispatch працює паралельно по принтерах — три вільні принтери з трьома завданнями стартують усі практично одночасно.

Що серіалізовано, а що паралельно

Коротка фаза DB-write (INSERT INTO print_archives) обгорнута в startup-lock, щоб SQLite не падав на database is locked від паралельних insert-ів. Лок утримується лише на ті кілька мілісекунд, що рядок коміттиться; FTP-завантаження, MQTT-команда start_print і будь-які swap-mode макроси біжать паралельно з тим, що робить наступний диспатчер. PostgreSQL успадковує той самий лок для симетрії, хоча йому це і не потрібно.

Тост активного диспатчу внизу праворуч відстежує кожен диспатч окремо — на екрані можуть бути одночасно кілька прогрес-барів FTP-завантаження. Щойно друк запущено на принтері, цей диспатчер відпускає свій слот; dispatch-tracker не чекає, поки друк закінчиться, лише поки upload + команда старту приземляться.

Тимчасовий "одне за раз через усю ферму" gate, що приземлився в середині 0.4.1, прибрали, як тільки startup-lock у диспатчер заїхав (c485db1).

Скасування під час диспатчу — що відбувається з чергою

Cancel поки диспатчер ще заливає 3MF або відправляє start_print (короткий проміжок між кліком Print Now / спрацюванням диспатчу і моментом, коли принтер репортить RUNNING) трактується як явна операторська дія — а не як збій диспатчу.

Це єдине місце, де черга сама опиняється в paused — два стовпці нижче це два різні набори станів із розділу Стани черги, а не один статус двічі.

Зріз Статус елемента Статус черги Статус архіву
Cancel прилітає під час FTP-аплоада / MQTT start cancelled paused cancelled
Диспатчер натрапляє на справжню помилку (FTP-таймаут, відмова start-print) failed error failed
Cancel прилітає вже коли друк у RUNNING на принтері n/a (обробляється stop-print) printing згідно результату stop-print

Семантична різниця важлива: коли черга йде в paused (а не error) — це сигналізує оператору, що нічого не падало — решта черги ціла, він сам вирішив зупинити один елемент. Можна оглянути решту й продовжити, коли готовий. До розрізнення, cancel під час дисптч-вікна заводив чергу в error зі щойно скасованим рядком як failed, що збивало з пантелику.

Скасовані рядки черги живуть поряд з failed і skipped у секції Issues на картці черги — щоб не захаращували живий pending-список, але лишались видимі для retry.

Restart скасованого елемента

Кожен скасований елемент у Issues отримує кнопку Restart (іконка RotateCcw), яка:

  • Повертає status назад у pending.
  • Дописує елемент у кінець черги (щоб він не стрибнув поперед того, що ти зачергував між тим).
  • Лишає історію архівів недоторканою — старий cancelled-архів живе для forensics; свіжий printing архів створюється коли елемент справді диспатчиться.

Той самий endpoint POST /api/v1/queue/{id}/retry, що відповідає за Retry на failed-елементах, обробляє і cancelled — він тепер приймає і failed, і cancelled як source-стани. Bulk-restart з секції Issues використовує PATCH /api/v1/queue/bulk з тим же retry-дієсловом.

Історія черги та архіви

У 0.4.0 жива черга та довговічна історія були розділені (міграція m019).

  • Жива черга показує лише незавершені елементи: pending і printing, плюс рядки failed / cancelled / skipped, які лишаються, щоб UI секції «Issues» з retry / unskip / remove далі працював.
  • Завершені елементи черги автоматично видаляються в мить, коли друк закінчився, — окрім випадку, коли на цьому принтері озброюється гейт очищення столу: тоді рядок чекає твоєї відповіді Очистити стіл або Повторити друк і зникає вже після неї. Закрити друк можуть два різні шляхи (живий обробник завершення і звірка), тож прибирання стоїть там, куди дістають обидва: коли звірка вигравала перегони, рядок завершувався одним шляхом і не прибирався жодним.
  • Минулі елементи черги живуть як архіви -- кожен рядок архіву несе queue_id (яка черга його диспатчила) та опційний batch_id (до якої партії N-із-M він належить). Архіви від external / direct-dispatch / Print-Now відкочуються на дефолтну чергу принтера, тож вони теж атрибутовані.

Термінальні лічильники в заголовку черги принтера (Total / Completed / Failed / Cancelled) рахуються з print_archives на кожне читання, а не зберігаються в черзі, тож не пливуть, коли черга авточиститься; кешованими на самій черзі лишаються тільки Pending і Skipped — вони описують живі рядки, які ніхто не прибирає.

Щоб побачити архівовані елементи черги, відкрийте сторінку Архіви та відфільтруйте за принтером. Невдалі диспатчі показують докладний error_message при наведенні (короткі коди причин і далі живуть у наявному полі failure_reason).

Архів від dispatch-time стартує як printing

Диспатчі з файлів бібліотеки тепер створюють рядок архіву одразу зі status='printing' -- ніяких миттєвих "Archived" бейджів під час вікна FTP+MQTT. Якщо диспатч падає після коміту рядка (FTP-помилка, помилка start-print), хелпер на свіжій сесії перемикає архів на failed / cancelled з виставленим докладним error_message, тож зомбі-рядок зі 'printing' ніколи не зависне в UI.

Видалення файлу бібліотеки -- що буде з елементами черги

Зовнішній ключ print_queue.library_file_id -- це ON DELETE SET NULL (міграція m018). Поверх цього видалення файлу бібліотеки застосовує додаткову in-app логіку, щоб SQLite-інсталяції (де PRAGMA foreign_keys за замовчуванням вимкнено) поводились так само, як PostgreSQL:

Елемент черги посилається на файл Результат
Зараз status='printing' API повертає 409 file_in_use з переліком queue_item_ids. Спочатку скасуйте або завершіть ці друки, потім повторіть видалення.
pending Елемент скасовується, а в waiting_reason записується «Source file deleted».
Будь-що термінальне Не чіпається — це історія.

Рядок скасовується, а не видаляється. Pending-завдання, яке зникло мовчки, не відрізнити від того, якого ніколи не ставили, — тож воно лишається в секції Issues і каже, що з ним сталося. (Викидання архіву в кошик робить те саме, з причиною «Source archive deleted».)

Саме видалення файлу бібліотеки — це м'яке видалення: файл іде в кошик і його можна відновити, але елементи черги, які на нього спирались, до того моменту вже скасовані.

Архіви зберігають свою окрему копію 3MF (потік диспатчу копіює байти у директорію архіву на старті друку) і виживають -- print_archives.library_file_id при видаленні виставляється в NULL замість каскаду.

POST /library/bulk-delete застосовує ту саму логіку для кожного файлу: файли, заблоковані друком, потрапляють у skipped_files замість того, щоб обвалити всю партію.

До 0.4.0 поведінка була інакша

Раніші версії використовували SET NULL FK без жодного in-app продовження -- видалення файлу бібліотеки лишало осиротілі елементи черги, що вказували в нікуди: черга не могла їх диспатчити, а пояснити це нікому не вдавалось. Ці рядки треба було чистити вручну.

Сповіщення черги

Подія Коли спрацьовує
Завдання додано в чергу Щось поклали в чергу.
Завдання черги стартувало Зачергований друк пішов; несе оцінку часу.
Завдання черги очікує Авточерга не змогла розмістити завдання — один раз на кожну окрему причину, щоб застрягла ферма сказала про це, а не мовчала. Несе waiting_reason.
Завдання пропущено Гейт require_previous_success відмовив завданню після збою на цьому принтері.
Завдання не вдалося запустити Диспатч упав.
Черга завершена Усі зачерговані завдання по всій фермі закінчились.
Черга принтера завершена Черга одного принтера спорожніла.

Шаблон кожної події редагується в обох локалях. Налаштовується в Параметри → Сповіщення.

Захист H2D від хибного reprint

Прошивка H2D Pro (серія 01.01.00.00) тримає gcode_state=FINISH 48--55 секунд після прийняття нового файлу, перш ніж перейти у PREPARE. Watchdog планувальника раніше відкочував елементи черги в pending на 45 с, якщо стан не зрушив -- і наступний тік планувальника редиспатчив завдання як "reprint", який принтер уже фізично виконував.

Watchdog тепер чекає до 90 с і виходить достроково за будь-яким із двох сигналів: gcode_state зрушив за межі pre-dispatch значення, або subtask_id зрушив за своє (принтер віддзеркалює submission_id, який BamDude згенерував, у наступному push_status, і на повільній прошивці це приземляється задовго до gcode_state).

Якщо вікно все ж минуло без жодного сигналу, елемент повертається в pending на нову спробу, а не падає одразу, — і лише після трьох таких спроб його фейлять, з повідомленням про те, що реально спостерігали (якщо весь час сушився AMS, це буде сказано прямо: це поширена причина, чому принтер приймає файл і не стартує). Один виняток: якщо на фізичній машині вже відпрацював свап-макрос старту, елемент лишають у printing, а лог кличе людину — бо повтор перекинув би плиту вдруге.

Ви більше не побачите репортів "queue stuck" від цього, в тому числі одразу після завершення друку на моделях H2D / H2C / H2S.

Поради

Нічні друки

Заплануйте довші друки на нічний час -- прокиньтесь до готових друків.

Комбінація з розумною розеткою

Поєднайте планування з автоматичним вимкненням для повністю автоматичної роботи.

Базується на документації Bambuddy.