Відновлення ферми після перезапуску¶
Після непідтвердженого завершення BamDude запускається з паузою нових автоматичних запусків. Можна увійти, оглянути ферму, зупинити друк або вимкнути розетку до дозволу нових робіт. Автоматичного відліку немає.
Така сама перевірка потрібна після першого оновлення з версії без цього захисту, за відсутнього чи нечитаного службового запису та після відновлення бекапу. Після штатного перезапуску автоматика зазвичай відновлюється по завершенні стартових перевірок. Пауза, яка вже чекала вашого підтвердження, зберігається й після штатного перезапуску.
Нова порожня установка може пропустити першу перевірку лише тоді, коли BamDude довів, що сам створив сховище й у ньому немає налаштованих пристроїв чи робіт. Наявної порожньої БД або незавершеного початкового налаштування недостатньо.
Після початку застосування даних чи зупинки служб для restore спершу перезапустіть BamDude. Банер просить перезапуск і не дозволяє зняти паузу в цьому процесі. Бекап, відхилений попередньою перевіркою, не змінює поточну паузу.
Дозволити нові запуски¶
- Перевірте принтери, столи та живлення. Зокрема — навантаження, яке спричинило аварію живлення або вимкнення інвертора.
- Прочитайте постійний банер на головній сторінці, у Черзі чи на сторінці Система.
- Натисніть Дозволити нові запуски та підтвердьте дію. Адміністратори мають це право типово; його можна надати окремо як Дозволити нові запуски ферми після відновлення.
API-ключ потребує відповідної області керування й права власника та доступу до всієї ферми. Ключ для окремих принтерів не може зняти загальну паузу. Підтвердження зі старої вкладки не зніме новішу паузу запуску.
Дозвіл нових запусків зберігає ручні паузи черг і перевірки чистого столу. Підтвердження належить усій установці: reconnect принтера його не скасовує й не створює окремого гейта допуску для принтера. Недоступний або зайнятий принтер і далі проходить звичайні перевірки черги.
Що залишається на паузі¶
- Нові друки з черг і прямі запуски, повторні друки та запуски калібрування.
- Призначення AutoQueue, автоматичне й заплановане ON розеток, нові автоматичні сушка та прогрів.
Додавання, перевпорядкування й скасування завдань залишаються доступними. Облік поточних друків та енергії триває. Заблоковане ON за розкладом не позначається виконаним: воно можливе лише тоді, коли після зняття паузи його початкове вікно ще чинне. Пропущені старти не відтворюються накопиченою пачкою.
Поточні друки й ручне керування¶
Принтер може сам відновити друк і нагрів після втрати живлення. BamDude спостерігає цей друк через наявну логіку відновлення; сам перезапуск сервера не надсилає повторний друк чи Resume. Загальна пауза не є електричним блокуванням і не зупиняє власне відновлення принтера.
Пауза стосується нової роботи. Вона не блокує завершення та макрос зміни столу друку, який уже триває. Reconnect не додає окремого підтвердження ідентичності цього друку. Звичайні перевірки друку й макросів залишаються.
Ручне керування, зокрема Resume, Stop, Cancel, світло, температури, переміщення, G-code й макроси, доступне з наявними правами та перевірками стану принтера. Автоматичне OFF і звичайний шлях захисного вимкнення теж лишаються доступними. За фізичні наслідки ручних команд відповідає оператор.
Інфо → Відновлення стану друку зберігає наявну діагностику й підтверджувані дії ремонту. Також показується завершений рядок, який досі утримує заголовок черги зі станом друку. Наявність невиконаної фізичної дії в діагностиці не скасовує її та не запускає повторно автоматично.
Якщо паузу не вдається зняти¶
Поки триває стартове відновлення, дочекайтеся його завершення. Якщо службовий запис неможливо зберегти, перевірте доступність і права тому даних та зберіть пакет підтримки; автоматика лишається на паузі. Після усунення проблеми сховища чи запуску перезапустіть сервер. Видалення службового запису не обходить перевірку: відсутній запис знову вимагатиме підтвердження.
Службовий стан належить цій установці й не входить у бекапи. Відновлення бекапу іншої установки не переносить її рішення «завершення було чистим». Захист розрахований на один керуючий бекенд на установку, а не кілька бекендів зі спільною БД ферми.