برامج اللوحات: كل لوحة على نسخة Klipper بسطر واحد

بعد تحديث Klipper يصبح البرنامج الذي على لوحات الطابعة (اللوحة الرئيسية، ولوحة رأس الطباعة على CAN، وبرنامج host على كمبيوتر الطابعة) أقدم من Klipper. وكثيرًا ما يتوقف Klipper عندها برسالة MCU Protocol error حتى تُبنى كل لوحة من جديد وتُبرمج: ‏make menuconfig ثم make ثم أمر برمجة يختلف من لوحة إلى أخرى. وسطر واحد يفعل ذلك لها كلها:

~/klipper-auto-eject/install.sh --firmware

هذا اختياري، ولا يُكتب شيء على أي لوحة قبل موافقتك. ويعرض تبويب التحديثات في صفحة الويب متى تتأخر لوحة، وفيه زر يفعل الشيء نفسه (من صفحة الويب). ويذكر ذلك سكربت التثبيت أيضًا في آخره.

ماذا يفعل

1. يجد كل لوحة يستخدمها Klipper (كل قسم [mcu]) ونسخة برنامجها. واللوحة التي عليها نسخة Klipper نفسها تُترك كما هي، وكذلك المجس الذي له لوحته الخاصة (Beacon وCartographer)، لأن عليه برنامج الشركة الصانعة.
2. يعرف إعدادات بناء كل لوحة، أي ما يضبطه make menuconfig: انظر من أين تأتي الإعدادات.
3. يبني برنامج كل لوحة وKlipper ما زال يعمل، كلٌّ في مجلده (~/.cache/klipper-auto-eject/firmware/<اللوحة>/)، فلا يُمس ~/klipper/out.
4. يقارن كل برنامج بما تقوله اللوحة عن نفسها: شريحتها، والأطراف التي تتصل عليها، وسرعة CAN، وسرعة المنفذ التسلسلي. والبرنامج الذي يجعلها لوحة مختلفة يُستبعد.
5. يعرض ما سيبرمجه بهذا الترتيب، ويسألك:

الترتيب	اللوحة	كيف	كلمة المرور
1	لوحات CAN (لوحة رأس الطباعة)	Katapult عبر CAN، بعد التأكد من المكان الذي يبدأ منه Katapult البرنامج	لا
2	لوحات USB (أغلب اللوحات الرئيسية)	سكربت البرمجة الخاص بـ Klipper، كما يشغّله make flash: Katapult إن كان على اللوحة، وإلا DFU (‏STM32) أو وضع الإقلاع (RP2040)	Katapult: لا. وDFU ووضع إقلاع RP2040: يطلبها sudo
3	جسر USB إلى CAN	Katapult، بعد اللوحات التي خلفه	لا
4	‏host (‏[mcu host]، برنامج الكمبيوتر نفسه)	يضع sudo الملف الجديد مكان القديم، ثم يُعاد تشغيل الكمبيوتر	يطلبها sudo

1. يوقف Klipper، ويبرمج، ثم يشغّل Klipper من جديد ويعرض النسخة الجديدة لكل لوحة. وبعد host يُعاد تشغيل الكمبيوتر كله بدلًا من ذلك: في بعض اللوحات (BTT CB1 وCB2) لا تحصل خدمة klipper-mcu على الأولوية الفورية إذا أُعيد تشغيلها وحدها، فيبقى Klipper في حالة startup.

اللوحة التي عليها محمّل الإقلاع الذي جاءت به (محمّل BTT بحجم 32KiB على لوحة Octopus مثلًا) تحتفظ به: يُكتب البرنامج بعده. وبعض لوحات STM32F4 لا تعمل وحدها بعد DFU: تنتظرها الأداة، وتطلب منك الضغط على زر RESET في اللوحة إن لم تعد.

ونوعان من اللوحات يُبنى برنامجهما ولا يُبرمج، وتعرض الأداة مكان الملف:

• لوحة على منفذ تسلسلي (UART)، لا يستطيع أي سكربت برمجتها: اكتب الملف بالطريقة التي كُتب بها أول مرة، وغالبًا من بطاقة SD؛
• لوحة CAN بلا محمّل إقلاع: اكتبه عبر USB الخاص بها أو SWD.

لا شيء أثناء الطباعة

لا يحدث شيء والطابعة تطبع أو متوقفة مؤقتًا، أو وKlipper ينفّذ أمرًا، أو وauto-eject يدفع القطع أو يبرّدها في الخلفية، أو وأحد السخانات يعمل. ويفحص ذلك مرة أخرى قبل أن يوقف Klipper مباشرة. وقائمة المهام التي فيها مهام تنتظر تُوقف مؤقتًا أولًا: شغّلها من جديد عندما تكون جاهزًا. وإن فشلت البرمجة، أو ضغطت Ctrl+C، يعود Klipper للعمل.

من صفحة الويب

إن كانت خدمة klipper-auto-eject على الطابعة (‏install.sh --push أو --farm، الإشعارات)، ففي تبويب التحديثات زر حدّث اللوحات تحت برامج اللوحات. يذكر اللوحات التي سيكتبها ويسألك أولًا. ثم يشغّل التحديث نفسه في الخلفية، وتظهر كل لوحة وهي تُبنى، ثم تُكتب، ثم على نسختها الجديدة. ويكون Klipper متوقفًا في أثناء ذلك. وبعد host يُعاد تشغيل الكمبيوتر، وتعود الصفحة بعد دقيقة أو اثنتين. ويمكنك إغلاق الصفحة: يستمر التحديث، ويعرض التبويب كيف انتهى لمدة يوم. ولا يبرز الزر إلا إن تغيّر كود اللوحات منذ نسختها.

لا أحد هناك ليكتب كلمة مرور، فبعض اللوحات لا يكتبها الزر إلا بعد إعداد يُجرى مرة واحدة. ويعرضه install.sh --firmware أول مرة تشغّله في الطرفية، ويطلب كلمة مرور sudo لذلك:

ماذا	أين	لماذا
قاعدة udev: يُسمح للمستخدم الذي يعمل به Klipper بالكتابة على لوحة في محمّل إقلاعها (‏DFU في STM32، ووضعا الإقلاع في RP2040 وRP2350، ومحمّل HID)	/etc/udev/rules.d/60-klipper-auto-eject-firmware.rules	لوحات USB: لا يظهر هل عليها Katapult إلا بعد دخولها محمّل الإقلاع
قاعدة sudo لأمر واحد بمعاملاته نفسها: نسخ برنامج host إلى /usr/local/bin/klipper_mcu	/etc/sudoers.d/klipper-auto-eject-firmware	‏host
تترك الخدمة التحديث يكمل إن أُعيد تشغيلها في الطريق (تحديث للإزالة التلقائية مثلًا)	/etc/systemd/system/klipper-auto-eject.service.d/firmware.conf	كل تحديث

برنامج host يعمل بصلاحيات root. ومع قاعدة sudo يستطيع أي برنامج يعمل بذلك المستخدم أن يضع برنامجًا من عنده مكانه، فأجب بلا إن كان أشخاص آخرون أو برامج أخرى تستخدم ذلك الحساب. ومن دون الإعداد يكتب الزر لوحات CAN والجسر، ويستبعد الباقي، ويعرض السطر الذي تشغّله. وتُستبعد كذلك اللوحة التي تحتاج إلى السؤالين (أدناه)، حتى يُجاب عنهما مرة واحدة عبر SSH. ويزيل install.sh --uninstall الملفات الثلاثة.

من أين تأتي إعدادات البناء

1. من اللوحة نفسها. البرنامج المبني بنسخة Klipper ‏v0.13.0-752 أو أحدث (أغسطس 2026) يحمل الإعدادات التي بُني بها، وKlipper يعرضها. لا يُسأل شيء.
2. من آخر بناء. بعد كل برمجة تُحفظ الإعدادات في <config>/firmware/<اللوحة>.config بجوار printer.cfg، حيث يعرضها Mainsail وFluidd.
3. من ملف إعدادات على الطابعة. ‏~/klipper/.config (ما تركه make menuconfig)، أو ملف .config في مجلد الإعدادات، مصنوع للشريحة نفسها وللأطراف نفسها. ويسألك قبل أن يستخدمه.
4. من سؤالين. اللوحة تقول ما شريحتها وعلى أي أطراف تتصل، فلا يُسأل إلا عما يعرفه صانعها: الكريستال (لوحات STM32) ومحمّل الإقلاع. ودليل اللوحة يذكرهما، وكذلك شاشة make menuconfig التي ضُبطت بها.

فاللوحة المبرمجة بنسخة Klipper أقدم تُسأل مرة واحدة على الأكثر، وبعدها تُعرف إعداداتها. والإجابة الخاطئة تعطي برنامجًا لا يعمل، وعندها تجب برمجة اللوحة يدويًا: إن لم تكن متأكدًا فانظر في دليل اللوحة أولًا.

ما يحتاجه

• المترجم الخاص باللوحات. إن لم يكن مثبتًا تقول الأداة ذلك ولا يتغير شيء:

sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi libnewlib-arm-none-eabi

وهو موجود أصلًا إن كان قد بُني أي برنامج للوحات على هذه الطابعة. - Katapult على لوحات CAN، وهو الإعداد المعتاد للوحات رأس الطباعة على CAN. وأداة البرمجة تأتي مع Klipper نفسه (lib/katapult). - للوحة RP2040 بلا محمّل إقلاع (‏BTT Eddy مثلًا): مكتبة libusb، لبناء rp2040_flash الخاص بـ Klipper مرة واحدة: ‏sudo apt install libusb-1.0-0-dev pkg-config.

عندما يتوقف

ماذا يقول	ماذا تفعل
الطابعة تطبع (أو متوقفة مؤقتًا، أو تسخن…)	شغّله من جديد عندما تكون الطابعة لا تعمل
لن تبقى اللوحة نفسها	الإعدادات لا تناسب هذه اللوحة: ابنها مرة واحدة يدويًا بـ make menuconfig. وفي المرة التالية تقول اللوحة إعداداتها
‏Klipper لا يحتفظ بهذه الإعدادات	إجابة لا تتفق مع الباقي (USB بلا كريستال مثلًا)، أو لم يعد هذا الخيار في Klipper: ابنها مرة واحدة يدويًا
‏Katapult يبدأ البرنامج من مكان آخر	لم يُكتب شيء. إجابة محمّل الإقلاع خاطئة: احذف <config>/firmware/<اللوحة>.config وشغّله من جديد
لم يرد أي Katapult	لم يُكتب شيء. أطفئ الطابعة وشغّلها، ثم برمج تلك اللوحة يدويًا
لم تعد اللوحة بعد	اضغط زر RESET في اللوحة، أو أطفئ الطابعة وشغّلها
الجسر بلا Katapult	ينتظر في وضع DFU: شغّل سطر dfu-util الذي يعرضه، أو أطفئ الطابعة وشغّلها لتعود إلى البرنامج القديم
استُبعدت: تحتاج هنا إلى كلمة مرور	من صفحة الويب فقط: شغّل install.sh --firmware مرة واحدة عبر SSH وأجب بنعم عن سؤال صفحة الويب

وما طبعه كل أمر موجود في ~/.cache/klipper-auto-eject/firmware/<اللوحة>/build.log.

خيارات أخرى

سكربت التثبيت يشغّل tools/firmware.py، ويمكنك تشغيله بنفسك عبر SSH:

python3 ~/klipper-auto-eject/tools/firmware.py status                     # كل لوحة مقارنة بـ Klipper
python3 ~/klipper-auto-eject/tools/firmware.py update --build-only        # يبني ولا يبرمج شيئًا
python3 ~/klipper-auto-eject/tools/firmware.py update --only toolhead     # هذه اللوحات فقط

‏update --yes لا يسأل شيئًا: واللوحة التي تحتاج إجابة تُستبعد، وكذلك اللوحة التي تحتاج كلمة مرور إن لم يكن أحد في الطرفية. وupdate --progress FILE يحفظ حالة التحديث في ملف JSON، وبه تتابعه صفحة الويب. و--moonraker URL للوصول إلى Moonraker على منفذ آخر.

وتحديث صفحة الويب يحفظ حالته في ~/.cache/klipper-auto-eject/firmware-update.json، وما طبعه في firmware-update.log بجواره.